The contract argument usually gets framed as certainty against flexibility, as if you were choosing a temperament. It is more useful to ask a narrower question: who carries the cost when the estimate turns out to be wrong, and what does carrying it cost them.
Fixed price
You agree a scope and a number. If the work takes longer, the supplier absorbs it.
That protection is real and it is not free. A supplier pricing fixed must cover the case where the work runs long, so the quote includes a risk premium. On a well-understood project that premium is modest. On a vague one it is large, because the supplier is pricing a distribution of outcomes rather than a plan.
The McKinsey and Oxford analysis of more than 5,400 IT projects found an average 45% cost overrun. A supplier quoting firm on a loose brief is either carrying that exposure in the price, or has not thought about it. Neither is good news for you, and the second is worse.
Its real failure mode is behavioural rather than financial. Once the price is fixed, every change becomes a negotiation. Both sides start defending the contract instead of improving the product, and the supplier’s incentive is to deliver the letter of the scope rather than the thing you actually needed. You get what you specified, which is only good if you specified correctly.
Fixed price works well for genuinely bounded work where the unknowns are few and named: a defined integration, a migration with known data, a discovery phase. We quote discovery fixed for exactly that reason. It stops working when the scope is a description rather than a specification.
Time and materials
You pay for the work done. Efficient, flexible, and honest about the fact that software estimates are forecasts.
It requires two things that are easy to say and harder to supply: trust, and real visibility into progress. Without both you are writing cheques against an assertion.
Its failure mode is drift. With no ceiling, nothing forces the conversation about what to cut. Scope grows one reasonable addition at a time, the burn rate stays constant, and the end date recedes without anyone making a decision they would recognise as a decision.
Capped time and materials
You pay for work done, with an agreed ceiling for the phase. If the cap is going to be reached, that surfaces while there is still time to change scope rather than after the money has gone.
You keep flexibility. The supplier carries the consequence of a bad estimate. And because the cap is per phase rather than per project, both sides get a regular, structured moment to look at what has been learned and re-plan, instead of one large bet placed before anyone knew anything.
What matters more than the contract
The same research found the worst overruns, the ones in the 200% to 400% range that threatened the organisations running them, clustered in projects with infrequent checkpoints. A quarterly review meant three months could pass before anyone noticed the project had drifted.
No contract structure survives that. A fixed price on a project nobody has looked at for a quarter produces a supplier quietly cutting quality to protect margin. Time and materials produces a bill nobody expected. The checkpoint interval does more work than the pricing model, and it costs nothing to shorten.
We work in two to three week releases for that reason. If something has moved, you find out in a fortnight.
What to insist on, whichever you choose
- Written assumptions. An estimate without them cannot be held to anything. When something moves you want to see which assumption broke, not argue about whether it was in scope.
- A change mechanism agreed up front. How a change gets priced, who approves it, how long that takes. Settle it before you need it.
- Working software on a fixed cadence. Not a status report. A percentage is easy to write and a demo is not.
- A defined stopping point per phase. Something that forces a decision rather than a renewal.
How we structure it
A short fixed-price discovery, because the scope of the investigation is knowable even when the scope of the build is not. Then the build on capped time and materials per phase, priced against what discovery found, with the assumptions written down.
If discovery shows the project should not go ahead as described, you have spent a small fixed amount to find that out. That is the cheapest useful outcome available at that stage.
More on where the budget goes in what custom software actually costs, on evaluating suppliers in choosing a development partner, and on the drift signals in why software projects run over budget.
If you are comparing proposals on different contract structures and cannot tell which is actually better value, send us what you have.
Common questions
Is fixed price safer than time and materials?
It transfers estimate risk to the supplier, who prices that risk into the quote. You pay the premium whether or not the risk materialises. It works well on genuinely bounded work, and badly on loose scope, where it pushes both sides into defending the contract instead of improving the product.
What is capped time and materials?
You pay for work actually done, with an agreed ceiling for each phase. You keep the flexibility of time and materials, the supplier carries the consequence of a bad estimate, and reaching the cap forces a scope conversation while there is still budget to act on it.
Which contract type avoids overruns?
None of them reliably. Across more than 5,400 IT projects the worst overruns clustered where checkpoints were infrequent, not around a particular contract model. Short review cycles do more to control cost than the pricing structure does.
Sources
- McKinsey & Company with the University of Oxford, Delivering large-scale IT projects on time, on budget, and on value. More than 5,400 IT projects: 45% average cost overrun. The most severe overruns concentrated in projects with infrequent checkpoints.
Written September 2026.
