Fixed price vs Time and materials

Strip away the vocabulary and this is a question about risk allocation. Software estimates are uncertain, more so than most other kinds of construction, because a substantial part of the work is discovering what the work is. Somebody has to carry that uncertainty. Fixed price says the supplier carries it. Time and materials says the buyer carries it. Everything else about the two models follows from that single difference.

Once you see it that way, the pricing behaviour makes sense rather than looking like sharp practice. A supplier quoting a fixed price must include a margin for the risk they are accepting, because across a portfolio of projects some will exceed the estimate and the ones that do not have to cover them. The alternative is a supplier who under-prices, and an under-priced fixed-price project is not a bargain for the buyer. It becomes a project delivered under margin pressure, where the cheapest interpretation of every ambiguous requirement wins, where testing is the first thing compressed, and where the commercial conversation about scope starts before the technical work is finished.

This is why the useful question is not which model is cheaper but which risk you can afford to carry. A well-run time-and-materials engagement usually costs less than the fixed price for the same work, because there is no premium being paid. It can also cost more, because there is nothing preventing it from costing more except your own governance. If you can absorb that variance, carrying the risk yourself is rational. If you genuinely cannot, paying someone else to carry it is equally rational, and the premium is the price of the insurance rather than an overcharge.

There is a second, less obvious asymmetry. A fixed price transfers the risk of the estimate being wrong, but it does not transfer the risk of the specification being wrong. If the scope is delivered exactly as agreed and turns out not to solve the business problem, the supplier has met the contract and the buyer has bought the wrong thing on time and on budget. That is a common and expensive outcome, and it is one that fixed price does nothing to protect against. Buyers who most need certainty are often the ones most exposed to it, because the pressure to fix the scope early is precisely what causes the specification to be written before anyone understands the problem.

Contracts create incentives, and incentives change behaviour long before anyone consciously decides to behave differently. It is worth being explicit about what each model rewards, including the model we prefer.

A fixed price rewards the supplier for delivering the agreed scope with less effort. Part of that is entirely healthy: it rewards efficiency, reuse and not gold-plating, and a supplier who finds a faster route to the same result keeps the benefit, which is a reasonable thing to reward. The unhealthy part is what happens under pressure. When effort runs ahead of the estimate, the supplier’s interest and the client’s interest separate. Ambiguity gets resolved in the cheapest direction. Improvements that were assumed rather than written become change requests. Testing and non-functional work, which are the easiest things to under-deliver invisibly, come under pressure. And the supplier has an active reason not to mention a better approach discovered in week six, because the better approach costs them money and earns them nothing.

The other consequence is the one buyers feel most. Fixed price makes change expensive and adversarial. Every adjustment becomes a commercial event with an estimate, a negotiation and an approval attached, and both sides quickly learn to argue about the boundary of the original scope. Time that should go into the software goes into the interpretation of a document written before anyone knew very much. That is not a failure of goodwill on either side, it is the contract working exactly as designed.

Time and materials rewards the supplier for continuing to be useful, which is a better alignment for uncertain work and an obvious risk in the other direction. The buyer is right to notice that the supplier is paid for time and controls how much time things take. The honest answer is that this model relies on a combination of reputation, visible output and the buyer’s ability to leave, and that a supplier who is not delivering value under time and materials should be replaced quickly rather than argued with. That is only possible if the arrangement is set up so that stopping is easy and progress is visible, which is why the next section matters more than any clause in the contract.

It is also worth saying what neither model rewards: writing things down for the people who come next, keeping the system operable, and refusing to build something that should not be built. Those come from the people and the working relationship rather than from the commercial structure, and no contract type substitutes for them.

A fixed price is a bet on an estimate, so the reliability of the estimate decides whether the arrangement is sound. Estimates are reliable in proportion to how similar the work is to work already done, and how much of the requirement is genuinely settled. Where a supplier has built something several times, the estimate is grounded in evidence and the necessary risk margin is small. Where the work is novel, or where the requirement is a page of ambitions rather than a specification, an estimate is a guess wearing a suit.

This is why detailed requirements have to exist before a responsible fixed price can be quoted, and why producing them is itself real work. Somebody has to decide what the system does at the level of individual behaviours, what the integrations are and how they actually behave rather than how their documentation claims they behave, what the data looks like in reality rather than in the schema, what the non-functional expectations are, and what acceptance means. Skipping that analysis does not remove the cost, it moves it into the delivery, where it emerges as change requests and disagreements.

The pattern that resolves this is paid discovery, which we would recommend for most substantial fixed-price work. A short, separately contracted phase produces the technical understanding, the architecture direction, the sequencing and the risks, and it produces them as a deliverable you own whether or not you continue with the same supplier. On the far side, a fixed price can be quoted against something real, and the risk margin is smaller because the uncertainty has been reduced rather than merely priced. It also gives both sides a cheap way to discover that they should not work together, which is worth a great deal more than it costs.

One warning about fixed prices offered without that analysis. When a supplier quotes a firm number against a thin brief, one of three things is happening: they have done this exact work many times and genuinely know, they have priced in enough margin to survive being wrong, or they intend to recover the difference through change requests. The first is fine and worth confirming by asking directly what they have built that resembles this. The third is common and is the source of most fixed-price projects that end badly. A supplier who asks uncomfortable questions before quoting is displaying the behaviour you want.

Estimates also decay. A number produced against requirements agreed six months ago, for a business that has moved on, is not a firm price in any useful sense. If a procurement cycle has taken a long time between specification and start, the honest thing is to revisit the scope before the work begins rather than delivering something that was correct at the time it was written.

Time and materials transfers risk to the buyer. That is a real cost and it should not be waved away, because without the right conditions it is genuinely the worse deal: the buyer pays for effort with no ceiling, no certainty and limited insight into whether the effort is well spent. Suppliers who prefer this model, ourselves included, have an obligation to be specific about what makes it safe rather than asking for trust.

Start with a fixed price for discovery. The first phase is the one you know least about, so it is the one that should be bounded. Paying a fixed sum for a piece of analysis that produces a written recommendation, an architecture direction and a sequenced plan gives you something you own, and it lets you judge the supplier on a real deliverable before making a larger commitment. If the discovery is poor, you have found that out cheaply, which is exactly what it is for.

Then cap the exposure. A budget cap, a not-to-exceed figure per phase or an agreed number of cycles before a decision point all achieve the same thing: the flexibility remains, but the commitment is bounded and renewed deliberately rather than by default. A supplier who will not accept any form of cap is asking you to carry unlimited risk on their word, and that is a reasonable thing to decline.

Insist on visible output every week, and be precise about what that means. Not a status report, not a percentage complete, not a burndown chart. Working software, deployed somewhere you can use it, built in your repositories through your review process where your own engineers can read the code as it is written. This is the single most effective control in the model, because it makes progress a matter of observation rather than of assertion, and because a problem is visible in week two instead of month four.

Keep the ability to stop, and keep it real. Short notice periods, no long lock-in, and a handover position that is true continuously rather than assembled at the end: your repositories, your cloud accounts, your CI, and documentation written as the work happens. If you could give notice today and be left with a running system your own engineers can operate, then the supplier’s incentive to keep delivering value is aligned with your interest every single week. That is a stronger protection than any clause about performance, because it does not require anybody to prove anything.

Finally, supply the attention the model requires. Time and materials assumes someone on your side prioritises, answers questions promptly and accepts work. Where that person exists, the model produces better software than a fixed scope would have. Where they do not, the team will make the decisions themselves and you will get a well-built version of somebody’s best guess. If nobody can do that job, say so at the outset, because it changes which model you should buy.

Presented as a binary, this decision forces buyers to choose between certainty they cannot honestly get and flexibility they cannot govern. Most mature buyers end up in the middle, and the two middle arrangements are worth knowing by name because they solve different problems.

Capped time and materials keeps the model but bounds the exposure. Work is charged on effort, priorities can change freely, and there is an agreed figure the engagement will not exceed without a further decision. When the cap is approached, the conversation is explicit: extend it, stop, or reduce the remaining ambition. The benefit is that flexibility survives while the budget stays governable. The point that needs stating honestly is that a cap is not a fixed price. If the cap is reached before the work is finished, you have spent your budget and you have whatever was built, and the value of the model rests on having watched the work weekly rather than discovering the position at the ceiling.

Fixed scope per phase splits the work into pieces small enough to be estimated with confidence, and prices each one after the previous one has taught everybody something. The scope of phase one is settled and quoted. It is delivered and accepted. Then phase two is defined, informed by what phase one revealed, and quoted on that better information. The buyer gets budget certainty in every increment, the supplier gets a scope they can price honestly, and the estimate risk shrinks because nobody is pricing work that starts nine months from now. The cost is administrative: several agreements rather than one, and a decision point between each, which in some organisations is a genuine burden and in others is exactly the governance they wanted.

Both arrangements pair naturally with a fixed-price discovery at the front, and that combination is what we would propose for most substantial work. Fixed price where the uncertainty is lowest and the deliverable is discrete, flexible arrangements where the uncertainty is real, and a bounded commitment throughout so nobody is asked to sign an open-ended one.

There are two other structures worth a brief mention because buyers ask about them. Target cost with a shared overrun, where both parties absorb part of the difference between the estimate and the actual, aligns incentives well but requires enough trust and enough open-book visibility that it usually only suits an established relationship. Outcome-based or milestone payments tie money to acceptance rather than to elapsed time, which is attractive and workable when the acceptance criteria are genuinely objective. Where the criteria are subjective, it just relocates the argument to the point of acceptance, which is later and more expensive than the point of definition.

A great deal of writing on this subject treats fixed price as an unsophisticated choice, which is unfair and unhelpful to the person who has to get a project approved. Many organisations can only spend money in particular ways. Capital budgets want a number. Boards approve totals rather than rates. Public sector procurement and framework agreements are frequently built around defined deliverables for defined sums. Where those constraints are real, an arrangement that cannot state a total is not a flexible option, it is an option that cannot be bought.

The productive response is to work with the constraint rather than to argue about the philosophy. Where a total is required, structure the work so that a total can be quoted honestly: a paid discovery first, then a phase priced against something real, with subsequent phases approved separately as the understanding improves. Where a rate-based arrangement is permitted but a ceiling is required, capped time and materials usually satisfies the approval process while preserving what matters.

Internal politics deserve an honest mention too, because they shape these decisions more than anyone writes down. A fixed price gives the person who sponsors the project a number they can defend and a supplier to hold accountable if it goes wrong. That is a real form of personal protection, and it is not unreasonable to want it. Time and materials asks the sponsor to defend an ongoing spend on the basis of judgement, which is harder in an organisation that does not extend much trust. If the environment is genuinely like that, choosing the model that can survive it is a sensible act rather than a failure of nerve, though it is worth knowing that the protection is partly presentational: a fixed price for the wrong specification still delivers the wrong thing.

Some contractual detail matters more than the headline model, and it is worth settling in either case. Payment terms and milestone triggers should be defined before work starts. Intellectual property should be assigned to you on creation rather than on final payment, because the alternative gives a supplier leverage exactly when a relationship is going badly. Acceptance criteria should be written in terms both sides interpret the same way. Warranty for defects against an agreed specification should be explicit under fixed price and stated rather than assumed under time and materials. And notice periods should be agreed at the start, when nobody needs them, rather than negotiated when somebody does.

Changing model mid-engagement is normal. A fixed-price project reveals that the scope was wrong. A time-and-materials arrangement reaches a point where the remaining work is finally well understood and the buyer wants a number. Neither is a failure, but both are handled badly often enough to be worth planning for.

Moving from fixed price to time and materials usually happens under strain, which is the worst condition for a commercial conversation. The trigger is typically a growing stack of change requests, or the discovery that the specification does not describe the system that is actually needed. The way to do it well is to stop and re-baseline deliberately rather than letting the variations accumulate. Agree what has been delivered and accept it. Agree what remains, in current terms rather than in terms of the original document. Then restart on a bounded arrangement, with a cap and a weekly rhythm of visible output. What does not work is drifting into time and materials by treating an ever-expanding change process as a substitute, because that combines the administrative cost of one model with the budget uncertainty of the other.

Moving from time and materials to fixed price generally happens from a position of strength, and it is usually a good sign. Once a system exists, the team knows the codebase and the remaining work is genuinely well defined, a supplier can price the rest with a small risk margin because the uncertainty has largely been resolved by the work already done. A common and sensible shape is running discovery and the early build on a bounded time-and-materials basis, then fixing the price of the later phases where the requirement has settled. Just be aware that the fixed price applies to a scope, so from that point onwards changes become variations again, which is the trade you are choosing.

Whichever direction you are moving, do three things. Write down what is being accepted at the switch, so the boundary is unambiguous later. Make sure the artefacts are already in your control, meaning your repositories, your cloud accounts, your CI and documentation written as the work happened, so that changing the commercial arrangement does not require anything to be untangled or transferred. And agree how change will be handled under the new model before you need it, because the first time a change arrives is not the moment to discover that both sides had different assumptions.

One last honest observation. Most requests to switch model are really requests to fix something else. A buyer asking to convert to fixed price mid-project is usually asking for control and predictability that they are not getting, and the underlying problem is often a lack of visible progress rather than the contract type. A supplier asking to convert to time and materials is usually saying the scope was underestimated, and whether that is reasonable depends on whether the scope changed or the estimate was optimistic. It is worth naming the real problem before restructuring the agreement, because a new contract over an unfixed problem produces the same difficulty in a different shape.