Fixed price or time and materials for a software build?
Both models fail in predictable ways. How to choose, and how to structure whichever you pick so incentives stay aligned.
The contract model is not an administrative detail — it decides who carries which risk, and therefore how both sides behave when something unexpected happens. Something unexpected always happens.
Fixed price transfers risk, at a price
It works when scope is genuinely knowable — a defined integration, a migration, a well-specified build. What you are buying is certainty, and the premium for it is real. What you give up is flexibility: every change becomes a negotiation, which is friction exactly when you are learning.
Time and materials rewards discovery
It suits work where the right answer emerges as you build — most product development. It requires trust, and it requires the client to stay engaged. Without engagement it becomes an open tab, which is how it earned its reputation.
Who carries which risk
Scope risk
- Fixed price
- Vendor — priced in as contingency
- Time & materials
- Client
Works when
- Fixed price
- Scope is genuinely knowable
- Time & materials
- The answer emerges as you build
Change costs
- Fixed price
- A negotiation each time
- Time & materials
- A conversation
Failure mode
- Fixed price
- Padding, and defending scope over outcome
- Time & materials
- An open tab with no checkpoint
Fix
- Fixed price
- Use it for discovery and defined integrations
- Time & materials
- Cap the budget, set a review cadence
| Fixed price | Time & materials | |
|---|---|---|
| Scope risk | Vendor — priced in as contingency | Client |
| Works when | Scope is genuinely knowable | The answer emerges as you build |
| Change costs | A negotiation each time | A conversation |
| Failure mode | Padding, and defending scope over outcome | An open tab with no checkpoint |
| Fix | Use it for discovery and defined integrations | Cap the budget, set a review cadence |
The structure that usually works
Fixed-price the discovery, because its scope is genuinely defined. Then time and materials against a capped budget with a defined cadence of reviews and a clean exit at each one. The client keeps control, the vendor is not incentivised to hide problems, and both sides can stop.
The structure that usually works
- 1
Fixed-price the discovery
Its scope genuinely is knowable, so the risk transfer is fair.
- 2
Cap the build budget
Time and materials, with a ceiling both sides can see.
- 3
Set a review cadence
Regular checkpoints where the client can redirect or stop cleanly.
- 4
Keep exit clean at each one
Nobody is incentivised to hide a problem until the next invoice.
Warning signs on either model
Regardless of which you choose:
- A fixed price quoted without seeing your data or systems
- A change-request process that is slower than the work it governs
- T&M with no cap, no cadence and no defined checkpoint
- Estimates presented without any range or stated assumptions
- Any structure where a vendor profits from the work taking longer