Project Pricing

Most pricing pages solve the seller's problem rather than the buyer's. A number big enough to be safe for every project is wrong for yours, and a number small enough to win the call gets corrected later, when you have already committed.

So BitsSolved publishes the thing that can honestly be published in advance: the shape of the deal. Not what your system costs, but how the number is arrived at, when you see it, what it covers, and what happens if you want to stop.

Every engagement runs in scoped phases with a fixed price agreed before any work starts. You can stop after any phase and keep everything built so far. At the end, the repository, the servers and the accounts are in your name.

The rest of this page is that model in detail.

A phase is a piece of work small enough to describe precisely and finish while the description is still true.

Each phase goes through the same four steps:

• Scope it. A call, then the scope written down: what the system has to do, who uses it, and what is deliberately not in this phase. The exclusions matter as much as the inclusions, which is why they are written down too.
• Quote it. A fixed price for that phase, agreed before work starts. The number you approve is the number you pay for that phase.
• Build it in the open. Working software you can open while it is being built, rather than a status report.
• Hand it over. Repository, servers and accounts in your name. No licence to keep paying for and nothing to unpick.

If the scope changes mid-phase (and on real projects it sometimes should), the quote changes in writing, before we carry on. You will not find a revised figure at the bottom of an invoice.

BitsSolved is a small studio. The fair question is what happens to your system if we stop answering the phone, so the answer is written down rather than implied, and none of it is charged for separately at the end:

• The source code, in your repository. Not a copy sent when the invoice clears. Your GitHub or GitLab organisation, from the first commit.
• The servers, in your account. Your cloud account, your VPS, your billing. We deploy to it; we do not own it.
• The domain and the DNS, in your name. Including the certificates and the mail records.
• The app store listings, under your developer accounts. Leaving a studio should never cost you your listing, your reviews or your users.
• The database, and a restore you have seen work. Backups are worth what the last successful restore proved.
• The documentation to run it. How it deploys, what the environment variables are, and what breaks if each one is wrong.
• No licence, no runtime fee, nothing to unpick. There is no BitsSolved component another engineer would have to replace.
• The right to stop. Each phase is quoted on its own. Stop after any of them and keep everything built to that point.

The point of that list is not that we expect to disappear. It is that another engineering team could pick your system up without talking to us first, and that is the only version of this promise worth anything.

Quote a whole project up front and one of two things has to happen. Either the number carries enough padding to survive every unknown, and you pay for risks that never materialise. Or it does not, and somewhere in month three the conversation stops being about software and starts being about the contract.

Phasing removes the guesswork from both sides:

• You are never quoted for work nobody has scoped yet. The first phase is priced against a written scope, not an ambition.
• What you learn in phase one can change phase two. Real users and working software produce better decisions than a planning document did.
• Your exposure is one phase, not one project. The most you can be wrong about us is a single phase.
• Nobody is arguing about change requests. Change is expected. It gets scoped and re-quoted, which is cheaper for you than a contract dispute.

It is also why, if the first phase you have in mind is bigger than the problem calls for, we will say so rather than quote it. A phase that delivers something you can use is worth more to both of us than a phase that delivers a document.

Send us the shape of the problem. The first call is free and is mostly us asking questions. After it, you get the scope in writing and a fixed quote for the first phase. Nothing is chargeable before you approve that quote.

It helps if you can tell us:

• What the system has to do, and for whom. A rough description is fine; a specification is not required.
• What exists today, if anything: a current site, an app, a spreadsheet everybody secretly runs the business on, a codebase from a previous developer or agency.
• What is actually forcing the decision now. A launch date, a customer, a system that has started failing, an investor conversation.
• Where you want this to be in a year, so phase one does not quietly rule it out.
• Any budget you have already set. Not so we can price up to it, but so we can tell you honestly whether it is enough for the phase you have in mind, and what would fit if it is not.

If what you need is outside what we do well, we will say so on that call rather than learn it at your expense.

Tell us what you are trying to build or fix, what exists today, and what is forcing the decision now.

You will get an honest answer about whether we are the right studio for it, a written scope, and a fixed price for the first phase, before anything is chargeable.