The choice between a fixed price contract and time and materials is usually framed as a choice about risk, which is correct, and then immediately mishandled, because both sides assume the risk goes away rather than moving.

It does not go away. In a fixed price arrangement the supplier carries the risk of the estimate being wrong, and prices that risk into the number. In time and materials the client carries it. The question is never which option removes uncertainty. It is which party is better placed to manage it, and whether the price of transferring it is worth paying.

The test that predicts which will work: can you write down what “done” means, in enough detail that two people would agree whether it had been reached? If yes, a fixed price is available to you and probably sensible. If you cannot, a fixed price contract does not eliminate the ambiguity, it just converts every future disagreement into a commercial negotiation instead of a technical conversation.

What a Fixed Price Contract Actually Buys

Certainty about the invoice, and nothing else. Specifically, it does not buy certainty about the outcome, the date, or the quality, all of which people assume come bundled.

It also carries a price. A supplier quoting fixed price adds contingency, because they absorb the overrun, and the size of that contingency scales with how vague the specification is. On a well-defined piece of work it might be modest. On a loosely defined one it can approach the cost of the work itself, and you pay it whether or not the risk materialises.

The second cost is behavioural. Once the price is fixed, every ambiguity resolves in the direction of less work, because that is where the supplier’s interest now lies. This is not bad faith, it is the incentive the contract created. A supplier who spots a better approach mid-build has no reason to raise it, and a client who realises a requirement was wrong faces a change request rather than a conversation.

Fixed price works well for genuinely bounded work: a migration with a known source and target, an integration against a documented API, a defined set of screens against an agreed design. It works badly for anything exploratory.

When Time and Materials Costs Less

Counter-intuitively, it often does, because you are not paying the contingency and you are not paying for change requests.

It suits work where the scope will legitimately change: a first version whose direction depends on what users do, an integration with a system nobody has documented, a rescue of a codebase whose condition is unknown until somebody looks. In all of those, a fixed price is really a fixed price for a guess.

What it demands from the client is attention. Time and materials without engagement becomes an open-ended bill, and the failure mode is a project that runs for months while nobody asks what was delivered last week. The control is not contractual, it is operational: a visible backlog, a demonstration at a regular interval, and someone on the client side empowered to change priority.

If nobody on your side can give that attention, be honest about it, because time and materials will not work well and no clause fixes it.

The Option Most Projects Should Use

A capped or phased arrangement, which is neither of the above and suits more software work than either.

Capped time and materials. Work is billed by time, with a ceiling. The client keeps the flexibility to change direction and the supplier carries the tail risk beyond the cap. Both sides retain an interest in efficiency, which neither pure model achieves.

Phased fixed price. A small paid discovery produces a specification, and only then is the build quoted fixed price against something real. This is the honest version of a fixed price, because the estimate is made after the unknowns are reduced rather than before. Our software RFP guide covers what that specification needs to contain.

Fixed price per increment. Each phase is separately quoted and separately agreed. You get budget predictability in chunks and the ability to stop, which is the most valuable right a client has and the one long fixed price contracts remove.

The common thread is that estimation accuracy improves enormously once some work has been done. Structuring the commercial arrangement to take advantage of that is worth more than any clause.

Where Fixed Price Projects Actually Fail

Not on price. On the boundary between scope and change.

Every fixed price project generates change requests, because specifications are written before anyone has used the thing. The health of the arrangement depends entirely on how those are handled, and that is decided by how precisely “in scope” was defined at the start rather than by anyone’s goodwill.

Two things reduce the friction. Agree in writing what happens to a change: who assesses it, on what basis it is priced, and how quickly. And keep a contingency on the client side too, because a fixed price with no client budget for change means every discovery becomes an argument.

The other common failure is acceptance. If the contract does not define how completion is demonstrated, the final payment becomes a negotiation over opinion. State the acceptance criteria alongside the scope, and prefer criteria somebody can test over criteria somebody has to judge.

Choosing in Practice

Ask what is genuinely unknown. If the answer is very little, fixed price is reasonable and you should expect to pay a contingency for the certainty. If a great deal is unknown, a fixed price only converts technical uncertainty into commercial friction.

Then ask what you can supervise. Time and materials rewards attention and punishes its absence. Fixed price asks less of you week to week and more of you upfront, in the specification, where mistakes are cheaper but harder to notice.

And ask how much the certainty is worth. Sometimes a board needs a number and the contingency is a fair price for that. That is a legitimate reason to choose fixed price, and it is a much better reason than believing it removes the risk.

Mecanik works under all three arrangements as part of our software development service, and recommends the phased version most often. The estimate produced after two weeks of discovery is worth more than the one produced before it, to both sides.

Frequently Asked Questions

Is a fixed price contract safer than time and materials? It is more predictable, which is not the same thing. A fixed price transfers estimate risk to the supplier, who prices that risk in as contingency, so you pay for it whether or not it materialises. It buys certainty about the invoice, not about the outcome, the date or the quality.

When is time and materials cheaper? When scope will legitimately change: a first version whose direction depends on user behaviour, an integration with an undocumented system, or work on a codebase whose condition is unknown until somebody looks. In those cases you avoid both the contingency and the change request overhead, and a fixed price is really a fixed price for a guess.

What is capped time and materials? Work billed by time with an agreed ceiling. The client keeps flexibility to change direction while the supplier carries the risk beyond the cap. It leaves both parties with an interest in efficiency, which neither a pure fixed price nor pure time and materials arrangement manages.

Why do fixed price software projects go wrong? Almost always at the boundary between scope and change, not on price. Specifications are written before anyone has used the software, so change requests are inevitable. Health depends on agreeing in advance who assesses a change and how it is priced, and on the client holding a contingency budget of their own.

Should I define acceptance criteria in the contract? Yes, alongside the scope. Without a defined way to demonstrate completion, the final payment becomes a negotiation over opinion. Prefer criteria somebody can test over criteria somebody has to judge, since testable criteria settle disagreements and judgement-based ones extend them.