Procurement treats this as a commercial preference. It isn't. It's a decision about who absorbs the cost of being wrong, and getting it backwards is how software projects turn adversarial.
What each model actually says
Fixed price says: we agree what gets built, and I carry the risk of estimating it badly. The supplier prices that risk in. You are paying a premium for certainty — typically 20–40% over the honest estimate.
Time and materials says: we agree a direction, and you carry the risk of it taking longer. You pay only for work done. You also pay for every hour spent going the wrong way.
Neither is generous. Both are rational. The failure is choosing the one that doesn't match how well you understand the work.
When fixed price is right
- The scope is genuinely knowable — a redesign of a defined set of screens, a migration with a known source and target, a specific integration.
- You have a hard external deadline (a funding milestone, a trade show, a regulatory date) and need the date to be someone else's problem.
- You cannot tolerate budget variance, and you'll accept scope shrinking to protect the number.
- The relationship is new and you want a bounded first engagement before committing to more.
The clause that decides everything: what happens when scope changes. If the answer is "we'll discuss it," you have a time-and-materials contract with extra steps and a worse mood.
When time and materials is right
- You're still discovering what the product should be. Fixing a price on an unknown just fixes the scope, and it'll be the wrong scope.
- You have someone technical on your side who can judge whether the hours are real.
- The work is continuous — a roadmap rather than a project.
- Priorities will change, and you'd rather redirect than renegotiate.
The failure modes
Fixed price fails by making every conversation a negotiation. The supplier's margin now depends on doing less, so a good idea in week three becomes a change request. Quality quietly becomes the release valve, because it's the one thing nobody itemised. You get exactly what was written down, which is rarely what you needed.
Time and materials fails by removing the deadline. Without a fixed end, there's no forcing function on scope, and "while we're in there" becomes the most expensive phrase in the project. Six months later you have excellent code and no product — see why agencies take six months.
The model I'd actually recommend
A fixed-price, fixed-duration window with negotiable content. Two weeks, one price, agreed up front. What goes into those two weeks is decided together and can change up to the moment work starts on it.
This inverts the usual trade. The supplier carries the delivery risk (the date and the price are fixed), and you keep the flexibility (what gets built can move). Nobody is incentivised to argue about scope, because scope isn't what's being protected — the window is.
It only works if the window is short. A fixed twelve-month engagement with flexible scope is not this; it's a retainer with a nice story.
What actually happens when scope changes
It will. The question is what the contract makes people do about it.
Under fixed price, a change request is a negotiation with a margin attached. The supplier has to price it, you have to approve it, and both of you are now slightly on opposite sides. The rational move for the supplier is to interpret the original scope narrowly; the rational move for you is to interpret it broadly. Neither of you is behaving badly and the relationship still degrades.
Under time and materials, a change is just next week's work. Frictionless — which is the problem. Nothing forces anyone to ask whether the change is worth its cost, because the cost never appears as a decision. It appears three months later as a burn rate.
Under a fixed window, a change costs something visible and immediate: it displaces something else in the same two weeks. That's the healthiest version, because the trade-off is explicit and made by the person who should be making it — you.
The hybrid most people actually want
In practice the shape that works for most product work is:
- A small paid discovery, fixed price. A few days to a week. Ends in a scope you both believe, not a deck. If the supplier won't do this, they're planning to discover on your budget.
- Fixed-price, fixed-duration delivery windows. Two or three weeks each, priced up front, content agreed at the start of each. Ship something real at the end of every one.
- Time and materials for the tail. Support, small changes, the long quiet period after launch. Nobody should be fixing a price on work that hasn't been imagined yet.
The discovery step is what makes the fixed prices honest. Without it, a supplier fixing a price is guessing, and the guess includes a margin for their own uncertainty that you're paying for.
Rate versus total cost
A €400/day supplier who needs two weeks of ramp-up costs more than a €900/day one who starts producing on Tuesday. This is the most common false economy in software procurement, and it survives because the day rate is the number in the spreadsheet and ramp-up isn't.
When comparing suppliers, ask each: when do I see the first working thing? That single date encodes ramp-up, process weight, staffing reality and confidence. It is more predictive of total cost than the rate is.
Clauses worth more than the rate
Whatever model you pick, these decide whether it works:
- IP assignment on payment, not on completion. If the project stops early, you should own what you paid for.
- Source access from day one. Not a handover at the end. If you can't see the repository, you can't verify anything.
- A named person. Contracts are with companies; work is done by people. Name them, and say what happens if they change.
- An exit that isn't punitive. A supplier confident in their work doesn't need a lock-in clause.
- Definition of done. Written down, in advance, in terms a non-engineer can check.
If you get those five right, the pricing model matters far less than anyone in the room currently believes.