Time and Materials vs Fixed Price: How to Choose in 2026

Ask five agencies to quote the same build and you get two shapes of answer: one number for the whole thing, or a rate card with an estimate range. Time and materials vs fixed price is usually framed as a pricing question. It isn't. Both models buy the same engineering at roughly the same market rate. What changes is who absorbs the gap between the plan and reality, and whether you can see that gap while there is still time to react.
We quote both. The failure we actually run into is never "the wrong model" in the abstract — it is a fixed price signed over a scope that was still moving, or a T&M contract where nobody on the client side opened the burn report until month four.
The only difference that matters: who owns the unknowns
Fixed price moves estimation risk to the vendor. One number, one date. If an integration turns out to be a swamp, that is the vendor's problem. If the build goes faster than feared, the vendor keeps the difference.
Time and materials (T&M) leaves that risk with you. You pay an agreed rate per role for hours actually worked. You get the savings when something turns out simpler than expected, and you get the bill when it doesn't.
Flexibility, transparency, "agile-friendly" — every other bullet you will read comparing these two models is a consequence of that one line.
What a fixed-price number actually contains

Three things, and only one of them is engineering.
The specified work. Whatever is written down, at the level of detail it is written down.
A risk premium. Nobody prices uncertainty at zero. The less of your scope is nailed to screens and acceptance criteria, the fatter that padding has to be, because the vendor is insuring you and gets exactly one shot at pricing the policy.
The cost of holding the line. Once the number is signed, the commercial incentive flips. Every change becomes a change order, and the safest way to protect margin is to build the letter of the spec. That is not vendor malice. It is arithmetic.
Which leads to the uncomfortable part: fixed price is at its most expensive exactly where buyers reach for it hardest — on a vague scope. A tight spec buys a thin premium. A hand-wave buys a thick one, or a suspiciously low bid that earns its margin back through change orders in month three.
What time and materials actually costs you
Variance, and attention.
Variance you can bound: an estimate range per task, a monthly cap, a stop rule. Attention you cannot outsource. T&M works when somebody on your side reads the burn report every week and reprioritises what is left. If nobody looks, it stops being a contract model and quietly becomes a standing order.
So T&M is not cheaper by nature. It is cheaper when the alternative was paying a premium for uncertainty that never materialised, and when you actually use the flexibility instead of just owning it.
When fixed price is the right call
- The scope is written down to screens and acceptance criteria, and you would sign it today without adding anything.
- The build is short. The further out the delivery date, the more of your money is premium rather than engineering.
- The vendor has shipped this exact shape before and is pricing memory, not hope.
- Third-party dependencies are few and documented.
- A tender or a board needs one number in one cell.
- You genuinely do not expect to reprioritise mid-flight.
Miss the first and the last of those and fixed price starts working against you: you pay for certainty, then spend the project negotiating your way out of it.
When time and materials wins
- The product is still moving. Sprint two teaches you something that changes sprint five.
- It is a rescue or a takeover. Nobody can honestly price a codebase they have not opened; a fixed quote on inherited code is a guess with a signature on it.
- You depend on APIs you do not control — a payment provider, a partner's backend, hardware someone else ships.
- You are buying a team rather than a project, quarter after quarter.
- You want the right to reorder the backlog every sprint without opening a commercial conversation.
Most long-running product work sits here. It is why so many agencies quote fixed price for a first release and move to T&M the moment the relationship becomes ongoing.
The middle options most buyers never ask for
The two models are the ends of a spectrum, not a menu of two. Four shapes sit between them, and all four are easier to negotiate than people assume.
Fixed-price discovery, then T&M build
A short paid discovery — architecture, data model, integration probes, clickable flows — produces the artefact that makes any later estimate honest. It is small, it is fixed, and it either de-risks the build or tells you not to do it at all. If a vendor will not sell you discovery on its own, that is worth a question.
Capped T&M
T&M with a not-to-exceed number per month or per phase. You keep the flexibility and the visibility; the vendor takes on the obligation to raise a flag before the cap rather than after it. This is the shape most of our own engagements take.
Milestone-priced epics
Break the roadmap into epics and fix a price per epic, one at a time, each priced after the previous one shipped. Every estimate is then made with real knowledge of the codebase instead of the fog at kickoff.
Retainer with rolling scope
Fixed monthly capacity, scope decided sprint by sprint. Predictable for finance, flexible for product. It only works with a named team and honest reporting.
The controls that make T&M safe to sign

T&M without instrumentation is a blank cheque, and buyers are right to be wary of it. Ask for these in writing before you sign anything:
- Task-level timesheets, exported with the invoice. Every invoiced hour should trace back to a named task and a person.
- A named team and a rate card by role. "A senior developer" is not a name.
- An estimate range per task before it starts, plus a monthly view of estimated versus actual. Estimates that are never compared with actuals never get better.
- A change log — what got added, what got dropped, what it cost.
- A cap and a stop rule. Everyone should know in advance what happens at 80% of the budget.
That is how our own billing works: invoices are generated from per-task timesheets, so every line traces back to a task, an engineer and a number of hours, and a client can reconcile a bill without asking us what it means. If a vendor cannot produce that view, the model is not really T&M. It is trust with extra steps.
Red flags on both sides
Fixed price. A quote that comes back fast and cheap without a single question about your data model, auth or integrations. A contract with change-order pricing left blank. A vendor who will not show you the assumptions the number rests on.
Time and materials. No cap. No timesheet detail. Engineers who rotate without notice. A burn report that only ever appears when you ask for it, and estimate ranges so wide they mean nothing.
Six questions that settle it
- Could you write the acceptance criteria today, and would you still agree with them in six weeks?
- If in week three you want to change priorities, is that a conversation or a contract amendment?
- Who carries the risk on the integrations you do not control?
- Are you buying a project with an end date, or a team for the next year?
- What will the invoice actually show, and can you reconcile it yourself?
- What does being wrong cost you — an overrun, or a missed market window?
Answer those honestly and the model usually picks itself. If most of your answers point at movement or a long horizon, fixed price is charging you for certainty you cannot use.
Where we land
We run most engagements on capped T&M with timesheet-backed invoices, and we quote fixed price when a scope is genuinely closed and short enough to price without guessing. The mechanics of running T&M well are written up separately in Time and Material Software Development, and our rates are on the prices page.
Weighing the two for a specific build? Send us the scope and we will tell you which model we would sign, and why — including when the answer is fixed price. Talk to us.
Either contract shape works better when the starting state is measured rather than assumed. If an existing site is part of the scope, this reads it for free: audit.lomray.com.



