Fixed Price vs Time and Materials: Which Contract to Use

What each model actually does with risk

Every contract model is a mechanism for deciding who pays when the work turns out to be harder than expected. That is the whole of it. The rest is administration.

Under fixed price, the supplier absorbs the overrun. Because they absorb it, they price for it — a competent firm adds a contingency of somewhere between twenty and forty per cent depending on how vague the brief is. You pay that contingency whether or not the risk materialises. If the work goes smoothly, the supplier keeps it.

Under time and materials, you absorb the overrun. There is no contingency in the rate, so the same project starts cheaper. If it runs long, you pay for the extra weeks. The supplier's revenue is unaffected by efficiency, which is the honest problem with the model and worth stating plainly rather than pretending otherwise.

How fixed price behaves when the project gets hard

The failure mode of fixed price is not that the supplier loses money quietly. It is that the incentive structure inverts the moment the estimate proves optimistic.

Once a fixed-price project is running behind, every hour spent is an hour of loss. The rational response is to reduce hours: interpret the specification narrowly, classify anything ambiguous as a change request, and resist scope conversations that would have been routine under a different contract. None of this requires bad faith. It is what the contract pays for.

You feel this as friction. A request that seems obviously within scope to you is obviously outside it to them, because the specification is a document rather than a shared understanding, and documents have edges. The relationship becomes contractual in tone at exactly the point where you need it to be collaborative.

Where fixed price genuinely works

When the specification really can be complete. Migrating a known dataset between two systems you can both inspect. Building an integration against a documented API with a sandbox. Rebuilding thirty screens that already exist, pixel for pixel. Anything where you could write down what "done" means and both parties would read it identically.

It also works well for a discovery phase — a fixed fee for two or three weeks that produces a specification, architecture and estimate. The scope of "produce these documents" is knowable even when the scope of the build is not, which is why this is the shape most sensible engagements start with.

How time and materials behaves when nobody is watching

The failure mode of time and materials is drift. Without a fixed endpoint, weeks accumulate. Features get built because they were mentioned, not because they were prioritised. Nobody is lying about hours; the project simply has no forcing function, and software expands to fill the time available with unusual enthusiasm.

This is manageable, but only with instruments. A T&M engagement with no budget ceiling, no sprint demos and no written priority order is not a contract model, it is an open tab.

• A not-to-exceed ceiling per phase, at which work stops for a conversation rather than continuing on assumption.
• Working software demonstrated at a fixed cadence — every two weeks is the common choice — on an environment you can use yourself, not a screen-share.
• A single written priority order that you own and can reorder, so what gets built next is your decision rather than a default.
• Time reporting broken down by feature rather than by person, so you can see where money is actually going.
• The right to stop at any phase boundary with the code and infrastructure in your hands.

With those five in place, T&M behaves well. Without them, the model deserves its reputation.

Which model suits which situation

The hybrid most good engagements settle on

In practice the argument is usually resolved by not having it. The structure that works for most builds runs in three parts.

1. A fixed-price discovery phase, typically one to three weeks. Output: a written specification, an architecture, a risk list and an estimate you can hold someone to. You should be able to take this document to a different firm — that is the test of whether it is real.
2. A capped time-and-materials build, phased. Each phase has a ceiling and ends in working software. You can stop, continue, or change direction at each boundary without penalty.
3. A support arrangement after launch, priced monthly, with a defined response time and a defined scope of what counts as support versus new work.

This gives you the thing fixed price is supposed to give you — a number you can plan around — without paying a contingency on unknowns that discovery is about to resolve. It gives the supplier protection against a scope that genuinely was not knowable. And the phase boundaries give both parties regular, low-cost opportunities to leave, which is what keeps an engagement honest.

What a cap should and should not mean

A cap is a point at which work pauses for a decision, not a fixed price with extra steps. If your supplier treats hitting the cap as their problem to absorb, you have quietly re-created fixed price and its incentives. If they treat it as a signal to raise it without discussion, you have no cap. The correct behaviour is that work stops, you are shown what remains, and you decide.

Terms that matter more than the pricing model

It is worth noting that several contract terms have more effect on your outcome than the choice between these two models, and they get a fraction of the attention.

• Intellectual property assigned to you on payment, explicitly covering code, designs and infrastructure configuration.
• Repository access from day one. If you cannot see the code as it is written, you cannot verify anything you are told about progress.
• A named team, with notice required before substitution. The people in the pitch and the people on the keyboard should be the same people.
• Defined handover: documentation, credentials, deployment process, and a working local environment someone else could set up.
• Termination for convenience with a short notice period. The ability to leave cheaply is what makes the rest of the contract enforceable in practice.

Negotiate those first. A generous pricing model attached to a contract that traps you is worse than a strict one you can walk away from.

If you are weighing up a proposal and are not sure which structure it really implies, we are glad to read it with you — including when the honest answer is that the terms need renegotiating rather than the price.