The two models, plainly
Time & materials (T&M): you pay for hours worked at agreed rates. The scope can evolve freely; the total is whatever the hours add up to. You carry the estimation risk.
Fixed price: the scope is defined up front and the price is agreed before work begins. The builder carries the estimation risk. Changes are priced separately, by agreement.
Neither is a scam and neither is a silver bullet — they allocate the same risk to different parties, and that allocation changes everyone's incentives.
The honest trade-offs
| Fixed price | Time & materials | |
|---|---|---|
| Budget certainty | Total known before you commit | Estimate only; totals drift with reality |
| Who carries risk | The builder | You |
| Scope flexibility | Changes go through change control | Change anything, anytime |
| Builder's incentive | Finish efficiently, scope tightly | More hours, more revenue — discipline required |
| Failure mode | Corner-cutting if scoped badly | Budget overrun if managed badly |
| Best when | Outcome definable up front | Outcome genuinely unknowable up front |
When time & materials genuinely wins
Fixed price is wrong for some work, and pretending otherwise would be the hype we claim to avoid:
- True R&D — if nobody can define what "done" looks like, a fixed price is a fiction that will be renegotiated later anyway.
- Embedded product teams — when you're hiring capacity to work an evolving backlog for a year, you're buying a team, not a deliverable.
- Rescue work on unknown codebases — until someone's been inside the code, any fixed number is a guess with a signature on it.
Why we chose fixed price anyway
Because most business software projects — websites, MVPs, platforms, integrations — are definable up front by a team that has built them before. Familiarity is what makes estimation honest: we can fix the price of a SaaS MVP at £12,500 because the risky parts (auth, deployment, data models) are systems we've shipped repeatedly, not experiments.
Publishing the prices is the enforcement mechanism. A number on a public page can't quietly grow after a discovery call — it keeps our scoping disciplined and gives you leverage before we've ever spoken.
Making fixed price work: what to check
Green flags — signs a fixed-price shop will deliver:
- Prices published, not "revealed" after a sales call
- A written scope you can read and understand before signing
- A change-control process explained up front, with changes priced before they're built
- You own the code, data and infrastructure at the end
- They'll tell you when the smaller tier — or no build at all — is the right answer
Red flags — where fixed-price projects go wrong:
- A fixed price quoted without a scoping conversation — someone's guessing, and the gap will surface as corner-cutting or "extras"
- Vague scope language ("modern responsive website") that could mean anything at delivery time
- Hostage clauses: code or hosting you don't own, "maintenance" you can't leave
- A price that undercuts everyone by half — the missing money comes out of the parts you can't see
Questions we hear a lot
What happens when the scope changes mid-project?
Real projects evolve, and a good fixed-price process expects it. Any change is specified, priced and approved before it's built — so the budget moves only when you decide it should, in writing, with the new number in front of you.
Isn't fixed price just hourly with a risk premium added?
There's some truth in that: a builder pricing unfamiliar work must pad for uncertainty. It stops being true when the builder has shipped the same class of system many times — the uncertainty is small, so the premium is too. That's why productized fixed pricing works and bespoke fixed pricing often doesn't.
Which model is cheaper in the end?
For definable scope, fixed price usually wins — not because the rate is lower, but because the scope discipline it forces is where budgets are actually saved. For genuinely open-ended work, honest T&M beats a fixed price that was fiction from day one.
Keep reading: Our full fixed-price menu · What a SaaS MVP costs · What a website costs