Every software quote eventually forces a choice between two contract shapes: a fixed price for an agreed scope, or time and materials billed against ongoing work. Most explanations of the difference stop at “fixed price suits stable requirements, time and materials suits changing ones.” That is true, but it skips the part that actually matters when you are the one signing: who carries the cost when the estimate turns out to be wrong, and what happens to the working relationship when it does.
What each model actually commits you to
A fixed price contract sets a total cost against a defined scope before work starts. The supplier estimates the effort, prices in a margin for the unknowns, and carries the risk if the work takes longer than planned. You get budget certainty. In exchange, you give up flexibility: a change of mind mid-project is not a quick conversation, it is a scope change request, usually with its own price tag and its own negotiation.
Time and materials bills for the hours actually worked, at agreed rates. You carry the risk that the project runs longer than expected, but you keep the ability to reprioritise, drop features, or change direction as you learn more. There is no scope change process because there is no fixed scope to change.
Neither model is more honest than the other. Both are ways of allocating a risk that exists regardless of which contract you pick: software estimates are wrong more often than they are right, and the interesting question is who absorbs that when it happens.
The question underneath “how clear is the scope”
Scope clarity is the usual test, and it is a reasonable starting point. A well-specified integration with a documented third-party API is a plausible fixed price job. A product where the roadmap depends on what users do with version one is not, no matter how detailed the initial brief looks.
But scope clarity at the start of a project is not the same as scope clarity for the duration of it. Two things tend to happen on real projects that a tidy fixed price quote assumes away:
- The spec turns out to be wrong once someone starts building against it. Third-party APIs behave differently under load than in their documentation. Data described as “mostly clean” turns out to need a migration pass. A permissions model that looked simple on a whiteboard has an edge case that touches half the schema.
- The business’s understanding of what it wants changes once there is something to react to. This is not scope creep in the pejorative sense; it is normal learning. It is also exactly what a fixed price contract is structurally bad at accommodating without friction.
Under a fixed price contract, both of these become change requests, and change requests are where the relationship tends to sour: the client feels nickel-and-dimed, the supplier feels the original estimate is being blamed for information nobody had at the time. Under time and materials, the same discoveries are just work, reprioritised and reported honestly. The trade-off is that “honestly” only holds if you have a way to check the reporting, which is the part most guides to this decision leave out.
Time and materials needs oversight, not just trust
The standard objection to time and materials is that it removes the supplier’s incentive to work efficiently. That is a fair concern, but the fix is not to default to fixed price out of caution — it is to build oversight into the T&M arrangement itself. In practice that means:
- Sprint-based delivery with a visible backlog, so you are seeing shipped increments rather than a monthly invoice and a status update.
- A capped budget per sprint or per phase, reviewed and re-authorised rather than open-ended.
- Time tracking or reporting granular enough that you can ask what the last forty hours produced and get a specific answer, not a narrative one.
If a supplier resists this level of visibility on a time and materials engagement, that resistance is worth more information than anything in their rate card.
Fixed price needs a real change process, not a footnote
The equivalent discipline on the fixed price side is a change control process agreed before it is needed, not improvised when the first change request lands. Worth pinning down in the contract itself: how a change is priced (day rate, or re-quoted against the original estimate basis), how long the supplier has to respond with a cost and time impact, and what happens to the original delivery date when a change is accepted. Without this, a fixed price contract quietly turns into a fixed price plus an unbounded number of undocumented extras, which is worse for both sides than either clean model.
Two details that matter more in the UK than the generic advice suggests
Most comparisons of these two models are written for a US audience and skip past a couple of things that matter for a UK engagement.
IR35 and how the team is actually engaged. If a supplier is resourcing your project with individual contractors rather than employees, the way the contract is structured — fixed deliverable versus ongoing time-based work under your direction — feeds directly into the IR35 status determination. A time and materials arrangement where contractors work to your day-to-day instruction looks more like disguised employment than a fixed price contract for a defined deliverable does. This is not a reason to pick one model over the other on its own, but it is a reason to have the conversation with whoever handles your tax compliance before you sign, not after HMRC asks.
Staged payments tied to milestones, not to time elapsed. On a fixed price contract, insist that payment milestones are tied to accepted deliverables — a working feature you can test, not a date on the calendar. Twenty-five per cent on signature and twenty-five per cent at week four gives the supplier no incentive to hit week four with anything usable. Twenty-five per cent on signature and twenty-five per cent on acceptance of the authentication and data model does.
The hybrid that most experienced teams actually use
In practice, the cleanest answer for a project of any real size is rarely one model start to finish. A short, fixed price discovery phase — typically two to four weeks — produces a specification detailed enough to price with confidence. The build that follows is fixed price against that specification if the domain is genuinely stable (a defined integration, a compliance-driven feature, a well-understood internal tool), or time and materials with sprint caps if the product is still finding its shape (anything customer-facing and early-stage, anything where the first release is explicitly meant to generate feedback that changes the second one).
This costs more upfront than jumping straight to a fixed price quote, because you are paying for the specification work separately. It is usually worth it: a fixed price quoted without a discovery phase is a guess wearing a number, and the margin the supplier prices in to cover that guess is money you are spending either way — you just do not see it itemised.
A checklist before you sign
- Can the scope be written down in enough detail that both sides would agree, in six months, whether it was delivered? If not, fixed price is a bet, not a plan.
- Has a discovery phase happened, or is the fixed price quote based on a sales conversation? A quote without discovery is pricing in ignorance, not confidence.
- Is there a documented change control process, with pricing and turnaround agreed now, not negotiated under pressure later?
- If it is time and materials, do you have sprint-level visibility and a capped, re-authorised budget, or just a monthly invoice?
- Are payment milestones tied to accepted, testable deliverables rather than dates?
- If contractors are involved, has IR35 status been considered against how the engagement is actually structured, not just how it is labelled?
- Does the product’s own trajectory argue for flexibility (early-stage, customer-facing, likely to change) or for certainty (internal, compliance-bound, well understood)? Let that answer the model choice before the supplier’s preferred way of billing does.