In the choice between fixed price vs time and materials, the question is who carries the risk of an overrun. Under a fixed price, you and the supplier agree what will be delivered and what it will cost before work starts, and the supplier bears the cost if the work takes longer; under time and materials, you pay for the hours worked at an agreed rate, and you bear it. Choose fixed price when you can describe the finished result. Choose time and materials when you cannot describe it yet, or when the work has no natural end.
This guide is for IT managers and budget holders in organisations that buy software work from outside suppliers, whether a new system or changes to one already in service. It covers how the two models compare, when each fits, what to agree before signing a fixed price and the warning signs in a quote.
What each model means
Fixed price. The supplier commits to a defined scope for a set sum. If the work takes longer than the supplier expected, the price stays the same. If you want something that was not in the scope, that is a change, and it is priced separately.
Time and materials. You pay for the time spent, at a daily or hourly rate, plus costs the supplier incurs on your behalf, such as licences or hosting. The supplier gives an estimate, not a commitment. You can change direction whenever you like, because nothing was fixed to begin with.
Who carries the risk of an overrun
Fixed-price projects have a poor reputation, and the failures follow a pattern. A buyer describes what they want in a page or two. A supplier keen to win the work names a price. Neither side has examined the existing data, the systems to be connected or the many small rules the business takes for granted. Work begins, the gaps appear, and the supplier either absorbs the overrun and cuts corners, asks for more money, treats every clarification as a chargeable change, or runs out of budget with nothing usable delivered. In each case the price was fixed and the scope was not.
When the scope is clear, a fixed price does what it promises: the supplier carries the risk that the agreed work takes longer than expected. That protection is not free. A careful supplier investigates the unknowns before quoting and includes an allowance for the uncertainty that remains, so part of what you pay is the price of certainty. One risk stays with you: that the scope you agreed turns out not to be what you needed. Putting that right means paying for changes.
Under time and materials, you carry the overrun. If the work takes twice the estimate, you pay twice the estimate. In return you pay only for time used, and you can stop, change or re-order the work at any point. The supplier has less commercial pressure to finish quickly, so you have to keep an eye on progress yourself.
Neither model removes risk. Each decides who holds it, and it is best held by whoever can control it. When the supplier can see the whole job, a fixed price is fair. When the job depends on discoveries nobody has made yet, or on decisions you will take as you go, the control is yours and so is the risk.
Fixed price and time and materials compared
| Fixed price | Time and materials | |
|---|---|---|
| Who carries overrun risk | The supplier, for the agreed scope. | You. |
| How much must be defined up front | Most of it: scope, assumptions, exclusions and acceptance checks. | Little. A goal and a rough estimate are enough to start. |
| How changes are handled | Each change is assessed and quoted, then added, swapped for something of similar size or deferred. | A change is simply the next piece of work, and the total moves with it. |
| Budget certainty | High, for the agreed scope. | Low, unless you set a cap and track what has been spent. |
| Suits which kind of work | A defined build with a clear finished state. | Exploratory work, ongoing support and open-ended improvement. |
| What to watch for | A quote given without questions, a vague scope, no acceptance checks, change rates you have not seen. | No estimate, infrequent reporting, nothing working to look at, an end date that keeps moving. |
When fixed price is the better fit
Fixed price suits you when most of these are true.
- You can say who will use the software, which tasks it must support and what it connects to.
- The main unknowns, such as the state of existing data, can be looked into before the price is set.
- You need one figure to get a budget approved.
- You do not have the time or the technical background to supervise the work week by week.
- The work has a clear end: a system delivered, or a database moved to a supported version.
When time and materials is the better fit
Time and materials is the right choice, and not a second-best one, in these cases.
- Nobody can yet say what finished looks like. A new product whose features will be shaped by how its first users behave is an example.
- The work is an investigation. Nobody can know how long an intermittent fault will take to trace before the cause is found.
- The work has no end. Support and small changes to a live system carry on for as long as the system does, and are normally arranged by the month, as with software maintenance.
- The system has not been assessed. The first weeks on undocumented code that someone else wrote cannot be scoped with confidence. A code audit is a way to find out what is there before anyone prices the work.
- You want to direct the work yourself. If someone on your side will set priorities every week and expects to change them often, a fixed scope gets in the way.
- The job is very small. Writing and agreeing a scope can cost more than the uncertainty it removes.
A fixed price for work like this is either a guess with a large allowance built in or the start of an argument about what was included.
Hybrid arrangements
Three common arrangements sit between the two models.
Paid discovery, then a fixed price
A short first stage, paid for separately, investigates the unknowns and produces a scope that can be priced. The build then proceeds at a fixed price. Make sure the output of the discovery is yours to keep, so that you could take it to another supplier.
Fixed price per stage
A large programme is divided into stages, each with its own scope and price, agreed one at a time. You have certainty about the stage in hand and freedom to change direction between stages. This suits modernising an existing system, where each stage reveals more about the next.
Capped time and materials
You pay for time used, up to an agreed ceiling. Check what happens when the ceiling is reached. In some agreements the supplier must finish the work at their own cost. In others they are only obliged to stop and ask.
What to agree before signing a fixed price
A fixed-price agreement is worth having when it settles these seven things. Each one comes with the question to put to the supplier.
- The deliverable. Who will use the system, which tasks it must support and what it must connect to. Describe outcomes: "a dispatcher can assign a job to an engineer and see it on the schedule", not "a scheduling module". Ask: what exactly is included, and what have you left out?
- The unknowns, resolved. Anything that could change the amount of work should be looked at before the price is set: the quality of existing data, access to third-party systems, the constraints of what is already there. A short paid discovery stage is the normal way to do this. Ask: what have you assumed about our data and the systems this connects to?
- Acceptance checks. How you will decide the work is finished: observable checks, named approvers and a process for resolving issues. Without them, "done" is a matter of opinion. Our article on acceptance criteria explains how to write them. Ask: how will we both know the work is finished?
- Assumptions and exclusions. Hosting, licences, data you will supply, content, training and ongoing maintenance. What is left out matters as much as what is included.
- Change control. New requests will come up. Agree in advance that each one is assessed and quoted, and that you can add it, swap it for something of similar size or defer it. Nothing should be added to the bill without your agreement. Ask: how is a change priced, and can I swap one item for another of similar size?
- Like-for-like quotations. If you are comparing suppliers, compare what each quote covers. A low headline price means little if the suppliers are pricing different outcomes.
- Whether fixed price fits at all. A defined build suits a fixed price. Exploratory work, open-ended improvement of an existing system and ongoing support do not, and are better arranged by the month.
Running the project once it is signed is a separate question. Our article on managing fixed-price projects in an agile way covers short cycles, demonstrations and handling change during the build.
Warning signs in a fixed-price quote
- It arrived quickly, with no questions asked.
- It is a single figure with a paragraph of description.
- There are no acceptance checks.
- It lists no assumptions or exclusions.
- Changes are not mentioned, or are charged at a rate you have not seen.
- It does not say who owns the code.
Questions to ask a supplier
The questions for a fixed price are in the checklist above. These cover the other model, and both.
Under time and materials
- What is your estimate, and what is it based on?
- Who will do the work, and at what rate?
- How often will I see working software and a statement of time spent?
- At what point will you stop and ask before spending more?
Under either model
- Who owns the code, and from when?
- What happens after delivery, including defects, support and hosting?
- If we part company, what will you hand over?
Common questions
Is fixed price always more expensive than time and materials?
Not always. A fixed price includes an allowance for the uncertainty the supplier is taking on, so for the same work it can cost more than a time and materials job that goes to plan. If the work overruns, time and materials costs more. You are paying for certainty, and its price depends on how much uncertainty was left when the quote was given.
Can a fixed-price project be agile?
Yes. The price, the outcomes and the acceptance checks are fixed; the order of work and the detail of each screen are not. Our article on fixed-price projects in an agile way explains how.
What happens if I want to change something after signing?
Under a well-written fixed-price agreement, the change is assessed and quoted before anyone acts on it. You then choose to add it at that price, swap it for something of similar size that is still to be built, or defer it to a later stage.
When should I avoid fixed price?
When nobody can yet describe the finished result, when the work is an investigation, or when it has no natural end, such as ongoing support. Paid discovery can turn the first case into one that can be priced.
How we can help
CodeFirst builds new software at a fixed price, and our fixed-price page explains how we handle scope, acceptance checks and changes. For a system already in service, we can look at it first with a fixed-price code audit before anyone commits to a figure for the work. Where a project is not yet defined well enough for a fixed price, we would sooner say so and suggest how to close the gaps than quote a guess.
If a fixed-price project has already gone wrong, our project rescue page describes how we assess what has been built and what it would take to finish.
Originally published on CodeFirst, a UK company that maintains and modernises business software.
Top comments (1)
"The price was fixed and the scope was not" is the whole failure mode in one sentence. From the supplier side, the thing that's made fixed price work for me is writing the exclusions list as carefully as the scope list. "Includes import of the current customer table" means very little until it sits next to "doesn't include cleaning duplicates or migrating order history." Buyers read the exclusions far more closely than the feature list, and that's exactly where the arguments would otherwise start.
The other one is agreeing what a change looks like before the first one shows up: a short written note saying what's being added, what it costs, and whether it moves the date, approved before the work starts. When that's in the contract, a mid-project request becomes a two-line email instead of a negotiation, and nobody feels nickel-and-dimed.