How we price a build

First: "the same project" usually is not. Two shops hear the same description and price different deliverables. One prices a working demo. One prices something your staff will use every day, with permissions, an audit trail, error handling and your existing data migrated in. Both are honest. They are not quoting the same thing, and nobody wrote down what they assumed. In our experience this explains more of the spread than anything else.

Second: how much already exists. Most custom software sits on a platform, a framework, or the last several projects that team did. Some fraction of what you need is written before anyone starts. But that fraction might be most of one area and almost none of another, and unless somebody has gone and looked, it is a guess.

Third: how fast the team actually builds. Not how fast they believe they build. Estimates run optimistic, and most optimistic where the work is least familiar, which is where the risk already is.

Get the first wrong and you are comparing different products. Get the other two wrong in the same direction and you are off by a multiple.

The first step is free and takes about three minutes. You tell us how your operation runs, what systems you depend on, and where work gets stuck. We come back with a report on where the leverage is: what to build, what to connect, what to automate. It is deliberately not a quote, and it is useful even if you never hire us.

If there is something worth scoping, we move to discovery and document the operating model: the real sequence of events from first contact through to the work being finished, billed and closed out. Where work comes in. Who touches it, in what order. Where information gets entered twice. What lives in a spreadsheet because the real system could not hold it. Which handoffs fail quietly. What you are obliged to prove, and how you prove it today.

That is not a feature list. A feature list says what someone wants the software to have. The operating model says what the business needs it to do, and that difference closes the first gap. Two vendors quoting from the same operating model can still assume different things about security, performance and what counts as finished, but now you can see where.

The document keeps working after the quote. Scope is written against it, acceptance is tested against it, the project is run by it.

All of this is free, including the technical review before quoting. No paid work begins until you accept a proposal. We would rather find out early, at our own cost, that this is not a match than sell you a scoping exercise to reach the same conclusion.

With the operating model settled, two questions remain: how much of it already exists, and how long the rest takes us.

Velocity comes from our build history. We do not estimate our pace. We derive it from work we have shipped, classified by kind: a self-contained subsystem with its own data model and security rules, a larger multi-part subsystem, a feature added to an existing base, a ground-up rebuild of a complex engine. Each class carries the pace we have actually sustained on that kind of work. The worst case stays in the model, labelled as the outlier, because a model that quietly drops its worst case is not a model. Where our history cannot measure something cleanly, we say so and size it by analogy to the nearest thing we can, rather than dressing a guess up as derived.

Completeness comes from reading the code, not from memory. Every area in the target operating model is checked against what exists today. We assess what is present, what is proven in production, what needs adapting to your rules, and what still has to be verified in your context. Those are not tidy buckets, a capability can be proven in production and still need substantial adaptation, and each carries a different amount of remaining work.

"Mostly built" does not mean the rest is small. The last part of a subsystem is routinely the expensive part, because that is where the edge cases, the integration and the real data live. So the model never subtracts a percentage from a total. It sizes what is left by the class of work it is, and records how confident we are in that sizing. The uncomfortable results are the useful ones: the areas everyone assumed were nearly done and are not. Those are what wrecks a project priced on assumption.

Then the arithmetic, read honestly. Remaining effort rolls onto the delivery stages, and each stage gets a verdict: comfortable, has slack, or tight. Where two hard problems land in the same stage, it is flagged as the pinch point before anything reaches you. The goal is not a number. It is a number that arrives with its weak spots already marked.

The table is invented and simplified. Real ones run longer and are specific to the business. It is here to show the shape of the reasoning.

None of these rows is free. The first two start from a working foundation, which makes them more predictable, but your rules and requirements are real development. The third is substantial build on a foundation. The fourth is different in kind: an integration we have never connected to can be estimated from documentation, but it cannot be verified that way, and we will not fix a price against it until it has been.

That is the point of decomposing. Three rows can be committed to. One has to be resolved first.

Effort is not a price, and the step between them is where a lot of quotes quietly go wrong.

The estimate covers the whole delivery, not just the code. Testing, environments, deployment, data migration, training, documentation and the handover that makes the system operable without us are all in the number. A quote that only priced the build will find the rest somewhere.

The commitment is fixed against an approved baseline: the operating model plus the acceptance scenarios, written down before work starts. Anything inside the baseline is ours to deliver at the agreed price, including being wrong about how long a piece takes. Carrying that variance is what a fixed price is for. Anything outside it is a change, priced and agreed in writing before the work happens, not absorbed quietly and argued about later. We can hold that line without inflating the price because the baseline is specific enough to tell the two apart.

What the model does not do is add a blanket percentage for risks nobody has named. Ordinary variance is inside the price. The one or two genuinely unverifiable items are handled directly, which is the next section.

Running the system is priced separately from building it. Hosting, support and maintenance are an ongoing service with their own cost, and folding them into a build price obscures both.

Measurement does not remove uncertainty. It locates it, which is more useful.

Most projects have one or two items that cannot be settled from the outside: an integration with a system we do not control, or a behaviour that has to hold up in a physical environment we have not worked in. You can spot them because informed people give very different answers about how hard they are.

The wrong move is to guess and bury it in the number. A generous guess means you overpaid for a risk that never arrived. An optimistic one means somebody absorbs a loss, and absorbed losses can reappear as change orders.

So those items get resolved first, inside an engagement you have already said yes to: a short, paid, explicitly scoped block of work with one job, turning unknowns into knowns. It has defined outputs, the findings, the evidence, and the decisions they force, and it happens before you are committed to the full build. Your exposure is capped at that block. If it resolves cleanly, the remaining number rests on evidence. If the thing genuinely cannot be done inside the agreed architecture, you find out then, for a bounded amount, instead of in month three for an unbounded one.

Naming the two things you are least sure about, in writing, before taking the project, is not a weakness in a proposal. It is usually the most informative thing in it.

Why publish the method rather than keep it?

Because the method is not the advantage. What is hard to copy is what it runs on. Measuring velocity from build history requires having the history, in enough volume and enough shapes for the classes to mean anything. Assessing completeness requires a platform substantial enough that the answer is interesting. Start every project from an empty directory and the audit returns nothing.

The other reason matters more to me. Opacity is what lets a padded quote and an honest one look identical on the page. Every vendor who explains how their number is built makes that a little harder.

We would rather be the one you can check.

You do not need us for any of this. These four questions work on any vendor, and the answers tell you more than the number does.

What exactly am I getting, and what did you assume I meant? The most expensive misunderstanding is two honest people describing different products.

Which parts already exist in something you have shipped, and which are being built for me? Ask area by area. This has the biggest swing of anything you can ask, and a vendor who cannot answer it has not done the work to know.

How did you arrive at the timeline? You are listening for whether it comes from completed work or from judgement. Judgement is not disqualifying. Not knowing which one you were just given is.

What are the two things you are least certain about, and what happens if one goes badly? Every honest answer names something. "Nothing, we have got it covered" means they have not looked, or they are not telling you.

A number on its own tells you very little. What matters is what sits behind it: what you are getting, what was assumed, and who carries it when the estimate is wrong. A good answer holds up under all four questions.

If you want to start without hiring anyone, take the assessment. It is free, it takes about three minutes, and it tells you where the leverage in your operation actually is.