Skip to content

Why fixed-price software fails — and how milestone billing fixes it

SigmaJunction · Engineering8 min read

Talk to anyone who has commissioned custom software twice and you tend to hear two different bad stories. The first project was fixed-price: the bid looked sharp, the change orders didn’t, and the engagement ended in an argument about what the spec really said. So the second project was hourly — transparent, flexible and somehow never finished, the invoices arriving on schedule while the software didn’t. The usual conclusion is that software vendors can’t be trusted. The more useful conclusion is that both projects ran on incentive structures that made the failure predictable.

A pricing model is not a commercial detail you bolt on after choosing a vendor. It is the incentive system the entire engagement runs on — it decides what the vendor is paid to do when reality diverges from the plan, which it always does. Fixed-price and hourly fail for opposite reasons, and the mechanics of both explain the alternative.

The fixed-price paradox

A fixed price is a promise about work made before the work is understood. Software estimation is hard even with full information; a fixed bid is typically produced in days, from a requirements document, before anyone has seen the legacy system, met the operators or found the exceptions the document leaves out. The vendor absorbs that uncertainty at a single number — so they price it in. Rationally, that means padding: a premium for everything they don’t yet know. But fixed bids usually happen in competition, which selects for the opposite: the winner is often whoever underpriced most aggressively — and starts the project underwater, needing to recover the margin somewhere.

There are two places to recover it, and both are invisible on the day you sign. The first is corner-cutting: tests not written, edge cases not handled, quality sacrificed — precisely the things you cannot see in a demo and will pay for later. The second is change orders. Once the bid is signed, every ambiguity in the spec becomes billable, and the spec stops being a plan and becomes a legal document read for advantage. For some firms this is not a failure mode but the business model: the bid is a loss leader and the margin lives in the change orders. If you have ever wondered how a competitive quote doubled by delivery, change-order farming is usually the mechanism.

That is the paradox. The fixed price was supposed to transfer estimation risk to the vendor. Instead it transferred conflict into the engagement — because a vendor who accepted a number they cannot honour has exactly one path back to profitability, and it runs through you.

Hourly is honest — and unaligned

Time-and-materials looks like the cure, and in one sense it is: it’s honest. You pay for what actually happens. No incentive to lowball, no reason to weaponise the spec, and scope changes are simply built rather than litigated.

But look at who is paid to do what. The meter runs whether the project converges or not. Nobody on the vendor’s side is economically rewarded for finishing — every hour is revenue and efficiency is a cost. This rarely produces deliberate slow-rolling; the mechanism is softer. It produces no resistance: no commercial pressure against scope creep, gold-plating or the third refactor. The estimate you were given at the start was never signed by anyone. It was a target, and targets on hourly projects recede at roughly the pace of spending.

Hourly also hands estimation risk to the wrong party. The vendor — the expert, the side with the information — carries none of the risk of their own estimate. You, the party least equipped to judge how long software takes, carry all of it. It is an honest model with a broken alignment: you agree about quality, mostly, and disagree — structurally, permanently — about cost and completion.

Fixed-price pays the vendor to argue about scope. Hourly pays them to keep going. Neither model pays anyone to finish.

What milestone billing changes

Milestone billing restructures the payment around the only thing you actually want: accepted working software. The scope is cut into milestones, each one a usable piece of software in production — a quoting engine a pilot team uses, an integration moving real data, never “project setup”. Each milestone carries its own price and acceptance criteria, written into the estimate as concrete, testable statements checked against the running system rather than a demo. You pay on acceptance, and the first invoice follows the first delivery, not the signature.

Two properties follow. Working software becomes the acceptance test — not hours logged, not a sign-off on a document, but a system your team can use. And stopping becomes your option at every boundary: accept a milestone, pay for it, and decide whether the next one still makes sense. You keep everything produced. The vendor re-earns the engagement one delivery at a time — which is the alignment fixed-price promised and never delivered.

One caveat, the important one: milestone billing only works if the estimate underneath it is real. Milestones bolted onto a padded or lowballed number are just a fixed-price project with more invoices — the same corner-cutting and change-order pressure, repeated at each boundary. The mechanism that makes the model work is not the billing schedule. It is whatever makes the estimate hold.

Why an estimate can actually hold

You cannot price what you haven’t understood — which is why estimates that hold start earlier than estimates that don’t. Before we price anything, we run a diagnosis: sit with the people who run the process, map the workflow end to end, put numbers on the manual steps and surface the constraints — the legacy system that can’t be switched off, the compliance rule nobody wrote down. A failed fixed bid prices a document. An estimate that holds prices an operation.

Scope discipline does the rest. A focused first version that ships in 2–3 months is not just faster to value; it is estimable. Estimation error compounds with scope, so a narrow v1 has fewer unknowns to be wrong about — and each later milestone is priced on the ground truth the previous one produced.

Then the term that keeps everyone honest: overruns are ours. If we under-scoped a milestone, the overrun is our cost — you never find it on an invoice. That single clause changes what an estimate is. A vendor who bills overruns produces estimates as marketing: the optimistic number wins the deal and reality is invoiced later. A vendor who eats overruns produces estimates as underwriting — every number is one we have to live with, the pressure that makes it careful. It is also why the diagnosis and the estimate are free: the estimate is not a deliverable we sell but a risk we take. The full mechanics are on the estimate and per-project pages.

What you give up

Milestone billing asks something of you, and it is worth naming. Mid-milestone scope changes are not absorbed silently. If you want to change what a milestone contains while it is being built, the change is re-estimated openly and priced at the boundary before work continues — you decide with the numbers in front of you. Coming from hourly, where changes are simply built, this can feel like friction.

It is the feature. Silent absorption is where fixed-price projects rot: the vendor “absorbs” your change and the cost comes out of a corner cut somewhere you cannot see — a skipped test, an unhandled edge case, a shortcut you inherit. A renegotiated boundary means every change gets an honest price and a real decision while you can still make one. The same discipline keeps milestones small and decision points frequent: you are never more than a few weeks from a point where you can redirect, pause or stop with working software in hand.

When milestone billing is the wrong model

No pricing model is universally honest, including this one. Milestone billing needs a scope that can be defined well enough to cut into deliverables — and some good projects don’t have one. If the roadmap is genuinely open-ended and evolving — a product organisation shipping continuously, priorities reset quarter by quarter — then forcing milestone boundaries onto it is theatre, and the honest structure is a dedicated team at a fixed monthly rate: capacity you direct, without pretending the scope is fixed. And if you are pre-revenue with strong distribution and a thin budget, the honest conversation is not about billing at all but about risk-sharing — the estimate becoming a valuation input in an equity deal rather than an invoice schedule. We’ve written separately about how we price risk we’re willing to own.

The test for any pricing model — ours included — is one question: when reality diverges from the plan, who pays, and what does that payment reward them for? Fixed-price pays the vendor to fight you about the divergence. Hourly pays them to be relaxed about it, on your money. Milestone billing with a real estimate pays the vendor to understand the work before pricing it, to keep milestones small and to finish — because until working software is accepted, nothing is owed. Incentives are not a substitute for a trustworthy partner. They are how you find out whether you have one.

Keep reading

Get the next essay by email

Software as an investment, applied AI and engineering practice — written for the people who sign the invoices.

One or two essays a month, no noise. Confirmed by email, unsubscribe in one click.

Want an estimate that actually holds?

Start with the free diagnosis — the estimate follows, milestone-priced, with overruns on us.