Finance departments prefer fixed price because it looks like certainty. Engineering teams prefer time and materials because it matches how software actually gets built. Both are right about their own concern, and the argument is usually settled by whoever is more senior rather than by what the project needs.
The useful framing isn’t which is safer. It’s who is better placed to absorb the risk that the scope changes — because that risk exists either way, and someone is paying for it.
What each contract actually does
Fixed price transfers scope risk to the vendor. They commit to a deliverable for a price. If it takes longer than estimated, that’s their margin. To survive doing this repeatedly, they price in a contingency — commonly a substantial one, because the downside is unbounded. You pay that premium whether or not the risk materialises.
Time and materials keeps scope risk with you. You pay for effort. If the work takes longer, you pay more. There’s no contingency baked in, so the expected cost is lower — but the variance is yours.
That’s the whole trade. Fixed price isn’t cheaper or safer in the abstract; it’s insurance, and insurance has a premium.
What fixed price does well
- Genuinely bounded work. A data migration, a defined integration, a redesign of a known set of screens, an upgrade to a supported version. If both sides can describe “done” the same way, fixed price is efficient and fair.
- Budget approval. Sometimes the organisational reality is that a variable number won’t get signed. A fixed number that’s 20% high but approvable beats a lower one that isn’t.
- Vendors you don’t know yet. For a first small engagement, fixed price caps your downside while you learn whether they deliver.
Where fixed price breaks
The failure is always the same shape: something is discovered mid-build that wasn’t in the specification.
Under fixed price, that discovery becomes a change request. Change requests need pricing, which takes days. Meanwhile the team works around the gap or waits. The commercial incentive now points the wrong way — the vendor is protecting a margin you fixed, so they interpret the spec narrowly; you interpret it broadly, because you assumed the obvious was included.
Nobody is behaving badly. The contract is doing what it was designed to do. But the relationship becomes transactional exactly when you need collaboration, and the accumulated change requests routinely exceed what T&M would have cost.
A rule that holds up well: if you can’t write the acceptance criteria today, you can’t fix the price today.
Where time and materials breaks
T&M isn’t automatically the mature choice. It fails when nobody is managing scope.
Without a defined outcome, “iterate” becomes “never finish.” Costs accumulate without a forcing function, and six months in there’s a working system nobody can point to as done. The vendor has no incentive to be efficient — not because they’re dishonest, but because nothing in the structure rewards it.
T&M requires an engaged client: someone reviewing burn against value weekly, prepared to cut scope, and willing to say stop.
The structures experienced buyers actually use
Capped time and materials. T&M with a ceiling. You pay for actual effort; the vendor absorbs overrun beyond the cap. You get most of T&M’s efficiency and most of fixed price’s protection. The cap is negotiated with a smaller contingency than a true fixed price, because the vendor only carries the tail risk. This is the most broadly sensible default for medium-sized work.
Fixed-price discovery, then T&M build. A short, genuinely bounded phase — two to four weeks — producing designs, architecture, a risk list, and a real estimate. Fixed price works here because discovery is specifiable. The build then runs T&M against a plan grounded in evidence rather than optimism. If a vendor won’t do this, ask why.
Fixed price per increment. Break the work into two-to-four-week chunks, each with its own scope and price, re-agreed as you go. Predictable per increment, adaptable overall. It carries more contracting overhead, which is the price of the flexibility.
Milestone-based fixed price with a change budget. A fixed price plus an agreed pool for changes — say 15% — that either side can draw on without renegotiating. It removes the adversarial dynamic from small discoveries, which is where most of the friction lives.
Terms that matter more than the pricing model
Whatever structure you choose:
- A written definition of done, per deliverable, agreed before work starts.
- A change process with a service level — changes priced within two business days, not “when we get to it.”
- Acceptance criteria and an acceptance window. Undefined acceptance is where fixed-price projects go to die.
- Payment tied to accepted deliverables, not calendar dates.
- Symmetrical termination. Thirty days both ways.
- What happens to unspent budget in a capped arrangement.
A short decision guide
- Scope genuinely fixed, acceptance criteria writable today → fixed price.
- Scope will evolve with user feedback, and you have someone managing it → T&M.
- Somewhere between, which is most projects → capped T&M, or fixed discovery then T&M.
- Unknown vendor, first engagement → small fixed price pilot, then reassess.
- Long-running product work with a stable team → T&M or a monthly team rate.
Frequently asked questions
Isn’t fixed price always safer for the client? It caps your price for the specified scope only. If the specification is incomplete, your exposure moves to change requests, which are priced without competitive pressure. Safety depends entirely on specification quality.
How large is the fixed-price contingency? Vendors don’t disclose it, and it varies with how much ambiguity they see. The clearer your specification, the smaller it is — which is the real argument for investing in discovery.
Can I get fixed price for a whole product build? Firms will offer it. Whether it survives contact with real users is another matter. If you go this route, insist on a change budget in the contract from day one.
What if the vendor’s estimate is wrong under T&M? You’ll know early if burn is reviewed weekly. That’s the discipline T&M demands — and the reason it fails for clients who set it up and look away.
Internal links: #7 MVP cost, #6 developer cost by region, #2 staff augmentation cost. External references: ISO/IEC/IEEE 29148 on requirements specification, for what a fixed-price scope document needs to contain. CTA: “Not sure which structure fits? We’ll recommend one before quoting.” → /contact