Fixed price or time and materials, in short
A fixed price contract sets one total for an agreed scope. The supplier carries the risk if the work turns out harder than planned. A time and materials contract pays for the hours actually worked, so you carry that risk, in exchange for the freedom to change course as you learn more.
Choose fixed price once the scope is firm enough that both sides could point to the same document and agree what's in and what's out. Choose time and materials while the destination is still moving.
This guide is for founders and operations leads at UK and EU companies of 10 to 200 people. You're weighing a proposal that names one of the two, or trying to work out which to ask for. It sets out what should decide which one fits, what a change should cost you under each, and two hybrid structures worth raising before you sign anything.
If you already have a proposal in front of you and want a second opinion on its contract type, that's part of what our software consulting covers.
What each contract type actually promises
A fixed price contract names a scope, item by item, and one total for delivering it. The supplier gets paid that total whether the work takes the time estimated or twice as long. Miss something out of the scope, and adding it later becomes a change: priced and agreed before anyone starts on it.
That stops being the supplier's problem only if it's written down.
Left unwritten, it tends to become exactly that: absorbed quietly, then priced into the next project instead.
A time and materials contract, sometimes called a day rate or hourly contract, names a rate and pays for the hours logged. There's usually an estimate alongside it, but no ceiling built into the model itself. Scope can move week to week. Drop a screen, add another, reorder what matters most, and the total reflects the hours that turned out to be needed.
The UK government's own guidance on pricing major contracts, part of its Sourcing Playbook, frames the choice the same way: as risk, not method. A fixed price transfers delivery risk to the supplier. The guidance calls day-rate and time and materials work cost-based pricing instead. That leaves the risk with the buyer, since payment tracks the actual cost of the work as it happens.
The guidance is blunt about what a fixed price needs to hold up. Its scope has to be fixed too, because floating or variable scope isn't suited to fixed pricing.
What should decide which one you choose
The test isn't the size of the project, or how much you trust the supplier. It's whether the scope is settled enough that changing it would be a change, not a discovery.
A scope earns that description once someone has answered the practical questions. Which screens or pages. Which systems it reads from and writes to. Who approves what, and what done looks like for each part.
Leave those open, and a fixed price forces the supplier to guess the answers and price the guess. Our guide to the software discovery phase covers what should produce that scope before any contract gets written.
Say you run a 60-person distributor and want a customer ordering portal. If nobody has counted how many orders still arrive by phone or who approves a credit limit, that's not yet a scope you can fix a price against. Time and materials, for a short first phase, is how you find those answers safely.
Time and materials also fits where the scope should stay open on purpose. A first version built to learn from real users. Ongoing work on something already live. A project where the point of hiring outside help is that nobody inside the company can yet say what done looks like.
There's a middle case worth naming: a supplier who offers a fixed price on a scope that isn't settled yet.
That price only looks fixed. It's a guess with a number attached. The guess gets protected later: padding you never see, or change requests for anything the brief didn't spell out.
Ask what the price assumes, and where a change would start. A vague answer is the real warning sign, not the contract type itself.
Why the early estimate is usually wrong, whichever you choose
The reason a settled scope matters this much predates any contract. Barry Boehm first plotted the pattern in 1981. Steve McConnell named it the cone of uncertainty in his 1997 book Software Project Survival Guide, and Construx, the estimation consultancy he now leads, still teaches it.
An estimate made before anyone has looked closely at a project can be off by a factor of 2 to 4 in either direction. So much is still unknown at that point that no other result should be expected.
Construx's own account of the pattern traces that range narrowing only once requirements, and then a detailed design, are written down. A fixed price agreed inside the wide part of the cone doesn't remove the uncertainty. It just moves who absorbs it, onto the supplier, who prices for close to the worst case it can imagine.
A discovery phase, or any written scope detailed enough to survive being read change by change, pushes the estimate further down the cone before the contract gets signed. That's the real argument for paying for a short scoping phase on its own terms, ahead of the question of how the build itself will be priced.
How each type handles a change
Under a fixed price, a change should follow a written process. You describe what's changed, the supplier prices the difference and states what it affects, and both sides agree in writing before work starts on it. Skip that process and two failure modes turn up on their own.
Small changes get absorbed quietly at first, for goodwill, and get priced into the next quote instead. Or every change becomes an argument over whether it was in the original scope, which wastes more time than building the feature would have.
Under time and materials, a change doesn't need the same negotiation, since you're already paying for hours rather than a fixed outcome. The cost of that flexibility shows up differently. Without someone on your side reviewing the hours and steering priorities every week, the total keeps climbing, with no natural point where anyone has to justify it.
Either way, the contract should say, in writing, how a change is proposed, priced and approved, and who on your side can approve one. Our guide to choosing a software development company covers what else a written scope should include, and how to compare it across suppliers.
Two hybrid models worth knowing
Neither contract type is the only option. A supplier who only ever offers one of the two is worth asking why.
A guaranteed maximum with shared savings
Government buyers sometimes agree a target cost alongside a cap. The supplier bids what it thinks the work will cost, and a ceiling gets set a fixed margin above that target. If the final cost lands below the target, both sides split the saving.
The Cabinet Office's Sourcing Playbook describes this fitting cases where the outputs are settled but the way of reaching them isn't. Scaled down for a smaller project, it looks like a not-to-exceed cap on time and materials billing, agreed one phase at a time. It carries the flexibility of hourly work, with the ceiling of a fixed price.
Money for nothing, change for free
Scrum's co-creator, Jeff Sutherland, presented a contract at the Agile 2008 conference for the case where a fixed scope feels premature but a client still wants budget certainty. The model fixes a price and a backlog of features upfront.
Two clauses do the work. The client can swap any unbuilt feature for a different one of similar size, at any point. And once the features still left stop being worth their cost, the client can end the engagement early. The supplier keeps a share of what's left, instead of working through a list nobody wants any more.
It answers a real problem with a plain fixed price. A team that finishes early earns nothing extra for it. A client who no longer needs the last few items is still paying full price for the whole list.
Not every supplier will offer a version of this model. It's still a fair question to raise before you sign a fixed price running longer than a few months.
Fixed price vs time and materials at a glance
| Fixed price | Time and materials | |
|---|---|---|
| What's agreed upfront | A defined scope and one total for it | A rate, plus an estimate of the hours |
| Who carries the risk of a harder-than-expected build | The supplier | You |
| How a change is priced | Separately, agreed in writing before work starts | Simply more hours, billed as they happen |
| Fits best when | The scope survives being read change by change, usually after a discovery phase | The destination is still moving: early product work, ongoing work on something live |
| What it asks of you | A scope precise enough to hold both sides to it | Someone reviewing the hours and steering priorities every week |
| The failure mode to watch for | Padding you can't see, or corners cut to protect the margin | A total that keeps climbing with nobody accountable for it |
What belongs in the contract either way
Some terms matter whichever type you choose.
The scope itself, written down, including what's explicitly left out. A definition of done for each part, and who tests it.
Who owns the code, the domain and the accounts once the project ends, and when each one moves to you. Our check on owning your website covers what to look for there. How a change is proposed, priced and approved, in writing, before work starts on it. And what you receive at handover: documentation, credentials, and anything the next developer would need without having to ask the last one.
A written scope and a weekly written update belong in every project regardless of how it's priced. They're what let you see risk building before the total does. That's how we structure the work we take on: a written scope before anything starts, and a written update every week, whatever the contract underneath says about price.
When each contract type is the wrong call
Fixed price is the wrong call when the scope is still a guess dressed up as a document. Nobody has watched how the current process runs. The list of screens keeps growing every time someone new joins the call. Or the project exists to find out what's needed rather than to build something already defined.
In any of those cases, a fixed price will be wrong in one direction or the other before the ink is dry. Pay for a short discovery first, or start on time and materials for a bounded phase, and fix the price once you both know what you're pricing.
Time and materials is the wrong call when nobody on your side has the hours to review the work and steer it. Without that, the total drifts, not through bad faith, but because nobody is saying stop to the ideas that seemed worth trying at the time.
It's also the wrong call when you need a number for a board before work starts, with no way to ask for more later. A board rarely accepts "we'll know the final figure once we're done."
Neither structure is a substitute for a supplier you trust. A fixed price won't stop a supplier from cutting corners inside the scope. Time and materials won't stop a slow one from taking twice as long as a better team would. Our list of questions to ask before you hire a software developer covers what catches that, whatever the contract says.
Ask for both quotes
Send your written scope to two or three companies on your shortlist. Ask each for a quote both ways: a fixed price, and a time and materials estimate with a not-to-exceed cap for the same work. Then read the assumptions each one attaches, not only the number.
A supplier confident in the scope will price the fixed option close to its own time and materials estimate, with a short, specific list of what it's assuming. One unsure of the scope will pad the fixed price, hedge it with a long list of exclusions, or steer you toward time and materials instead. That choice tells you something about how solid it thinks your brief is.
Still working out which companies to send it to? Our guide to choosing a software development company sets out the questions worth asking before either quote lands.
Questions
Can one project use both fixed price and time and materials?
Yes, and it usually works better split by phase than mixed within one. A first release built from a settled scope can be fixed price. The ongoing work that follows, where priorities shift as real users respond, tends to fit time and materials better. Treat each phase as its own pricing decision rather than forcing one model to cover both kinds of work.
Does a fixed price protect us from a supplier cutting corners?
Not by itself. A fixed price fixes the total; it says nothing about what counts as finished. Pin down testing, what done means for each part, and who checks it, in the written scope itself. Without that, a supplier under margin pressure has an obvious place to save time: the parts nobody wrote down.
How do we compare a fixed price quote against a time and materials one?
Compare what each includes before you compare the number attached to either. A fixed price that leaves out testing, documentation or handover costs more later, when someone else has to add it. A lower day rate from a slower team can cost more in total hours than a higher rate from a faster one. Ask each company what its price assumes, and check the assumptions before the total.
How we wrote this: drafted with AI, then checked and edited by the people who build our projects. Figures come from our own work or from the linked sources.