Fixed price or time & materials? How to buy custom software without overruns
Large IT projects run 45% over budget on average. Contract structure is only part of the fix.
Listen to the summary ·
Read the transcript
Large IT projects run 45% over budget on average and deliver 56% less value than predicted, in a McKinsey and University of Oxford study of 5,400 projects.
The average hides the real risk. In Flyvbjerg and Budzier’s study of 1,471 IT projects, the average cost overrun was 27%. But one project in six was a black swan, with a cost overrun of 200% on average, and nobody knows in advance which ones.
The difference between fixed price and time and materials is who pays when the estimate is wrong. Under fixed price the vendor does. Under time and materials the buyer does. In the guide’s illustrative example, a time-and-materials buyer on a $60,000 estimate pays $76,200 at the average overrun and $180,000 for a black swan.
Time and materials fits better for research, an ongoing roadmap, or a team with strong in-house product leadership. Then protect the budget with short sprints, a demo at the end of each, and the right to stop at any time.
For most new products, the safest structure is both: a short fixed-fee discovery sprint that resolves the unknowns, then a fixed-price build quoted on what it found. Payments follow milestones you have seen demoed as working features.
The guide below covers capped time and materials and the questions to ask before you sign.
AI-generated voice summary of this guide.
Ask any CTO about their worst vendor experience and you will hear the same story: a project that was “80% done” for six months while the invoices kept arriving.
The averages are only half the story. When Flyvbjerg and Budzier studied 1,471 IT projects, the average cost overrun was 27%, but one project in six was a “black swan” with a cost overrun of 200% on average and a schedule overrun of almost 70%. The risk in software is not that every project runs a little late; it is that a few run catastrophically over, and nobody knows in advance which ones.
Why overruns happen
- Scope is estimated before anyone understands the problem.
- Progress is reported in hours spent, not software shipped.
- Risky unknowns, such as integrations, data and performance, are left until the end.
All three come down to the same thing: the price is set at the moment the buyer and the vendor know least. A contract model can move the risk from one side to the other, but it cannot remove an unknown. Only work can do that.
Fixed price vs time and materials: who carries the risk
The real difference between the two models is who pays when the estimate is wrong. Under fixed price the vendor does; under time and materials the buyer does. Everything else follows from that.
| Aspect | Fixed price | Time and materials | Discovery, then fixed price |
|---|---|---|---|
| Budget | Known up front | Open, set by hours | Small fixed fee, then a known price |
| Overrun risk | Vendor | Buyer | Vendor, on a scope both sides understand |
| Scope changes | Change requests | Any time | Change requests, with the riskiest unknowns already resolved |
| Main risk | A padded price, or cut corners | Hours grow without progress | Two weeks before the build starts |
| Best for | Well-understood products | Research and evolving roadmaps | Most new products, apps and AI agents |
What the contract definitions say
The U.S. government’s procurement rules state the trade-off more bluntly than most vendors do. They govern federal contracts, not private ones, but they are a neutral reference written from the buyer’s side, not a vendor’s.
- Fixed price. FAR 16.202-1 says a firm-fixed-price contract “places upon the contractor maximum risk and full responsibility for all costs and resulting profit or loss”.
- Time and materials. FAR 16.601 says a time-and-materials contract may be used “only when it is not possible at the time of placing the contract to estimate accurately” the extent or duration of the work. It must also carry a ceiling price, and a contractor that goes past the ceiling does so at its own risk.
Read together, the rule is simple. Time and materials is the exception for work nobody can estimate, and even then the buyer gets a cap.
A worked example: the same overrun under each model
Take a build estimated at $60,000 and apply the overruns from the Flyvbjerg and Budzier study above: 27% on an average project, and about 200% on the one project in six that becomes a black swan. The figures are illustrative arithmetic, not a client case.
| Model | On estimate | Average overrun (27%) | Black-swan overrun (200%) | Who absorbs the rest |
|---|---|---|---|---|
| Time and materials | $60,000 | $76,200 | $180,000 | Nobody: the buyer pays it all |
| Capped T&M, cap $72,000 | $60,000 | $72,000 | $72,000 | The vendor, or the scope, depending on the cap clause |
| Fixed price | The quote | The quote | The quote | The vendor; approved change requests excepted |
| Discovery, then fixed price | Fee plus quote | Fee plus quote | Fee plus quote | The vendor, on a scope discovery has tested |
The arithmetic: $60,000 × 1.27 = $76,200, and $60,000 × 3 = $180,000. The cap of $72,000 is 120% of the estimate, a figure we picked for the example.
Two things the table hides. A fixed quote on a poorly understood scope is often higher than $60,000, because the vendor prices in the black-swan risk it is taking on. And under a cap, a vendor that hits the ceiling with work unfinished has every reason to stop. The discovery row is the only one where the price is set after the biggest unknowns have been tested, which is why the quote can be both fixed and close to the real cost.
When time and materials is the better choice
Fixed price is not always right, and a vendor that says otherwise is selling. Time and materials, or a dedicated team on a monthly fee, fits better when:
- The work is research: you are exploring whether something is possible at all.
- The roadmap is ongoing: a product team that reprioritizes every sprint will spend more time on change requests than on software.
- You have strong in-house product leadership that wants to steer week by week.
In those cases, protect the budget with short sprints, a demo at the end of each one, and the right to stop at any time.
When fixed price works
Fixed price works when both sides can describe what “done” looks like: the screens, the integrations, the data, the performance targets and the acceptance criteria. It fails when that description is guessed rather than known, because the vendor either pads the price heavily or protects its margin later by cutting corners. That is why the quote should come after discovery, not before.
The same holds for an app that already exists. If you built a prototype with an AI tool, an audit does the job of discovery, and our production-readiness checklist for AI-built apps lists what it should test before anyone quotes the fix list.
Capped time and materials and other hybrids
Most real contracts mix the two models, and the hybrids are often the best fit. Four are common:
- Capped time and materials. Hourly billing with a not-to-exceed price, the private-sector version of the FAR ceiling. It protects the budget, but only if the contract says what happens at the cap: the vendor finishes at its own cost, or work stops and the remaining scope is renegotiated.
- Fixed price per milestone. The project is split into milestones, each with its own scope, acceptance criteria and price. Later milestones can be re-quoted once earlier ones have answered the open questions.
- Fixed-fee discovery, then fixed build. A short paid phase resolves the unknowns and produces the quote for the build. This is the structure we use, described below.
- Dedicated team. A monthly fee for a stable team that works through a backlog you prioritize. It replaces the fixed price when the roadmap is ongoing, and the protection is the right to stop at the end of any month.
Pick the hybrid by where the unknowns are. Unknowns at the start favor discovery first; unknowns that only appear later favor milestone pricing; a roadmap that never ends favors a team.
How milestone payments work on a fixed-price build
On a fixed-price build, payments follow milestones, and each milestone is a working feature you have seen demoed, not a document or a percentage of hours. That keeps the vendor’s cash flow tied to software you can use.
- DeliveredA working feature, demoed
- AcceptedThe tests or behaviors that count as done
- PaidPayment follows acceptance
Agree three things per milestone before work on it starts: what is delivered, how it is accepted (the tests or behaviors that count as done) and what is paid. If a milestone slips, the payment slips with it.
Fixed price for AI projects
AI work can be priced fixed, but the unknowns sit in different places. The model is rarely the risk. The data is: whether it exists, how clean it is, and whether the agent can reach the systems it needs. The other risk is the quality bar, so agree an evaluation set and a pass threshold before the build is quoted, or nobody can say when the work is done.
That makes discovery more important for AI than for a standard app, because the prototype is the only way to test both on real data. How AI agent budgets break down by agent type is covered in AI agent development cost, and why so many AI pilots never become products in AI pilots to production.
A better structure
Split the work in two. First, a short fixed-fee discovery sprint that resolves the biggest unknowns and produces a prototype. Then a fixed-price build, quoted only once the scope is genuinely understood.
“You shouldn’t pay for a vendor to learn your business on an open-ended clock.”
This is how we sell our own work, and the details are on our pricing page. The Discovery Sprint is a two-week, $5,000 fixed fee, credited to the build: workshops with a senior architect, a working prototype on your real data, an architecture and integration plan, and a fixed-price quote. The build that follows is $25k–$120k depending on scope, runs 6–16 weeks in two-week sprints with live demos, and includes 30 days of post-launch support. Scope is locked after discovery and changes go through change requests. For an ongoing roadmap, a dedicated team from $12k per month replaces the fixed price.
What a discovery sprint should produce
A discovery phase is only worth paying for if it leaves you with something you could take to any vendor. At the end of it you should have:
- A working prototype of the riskiest part of the product, built on your real data or systems.
- An architecture and integration plan that names every external system, how it is accessed and what can go wrong.
- A scope document with features, priorities and acceptance criteria, written in plain language.
- A fixed price, a timeline and a milestone plan for the build.
- A list of assumptions and open risks, each with an owner.
If a vendor’s discovery ends with only slides and an estimate range, the unknowns are still there; they have just been moved into the build.
How to compare quotes from different vendors
Quotes are only comparable when they describe the same scope. Ask each vendor to price against the same scope document, and then compare what each one includes: testing, security review, deployment, documentation, post-launch support and who owns the code. A low hourly rate multiplied by an open number of hours is not a lower price, and a fixed quote that excludes testing is not a fixed price.
How to keep a fixed-price project on track
- Demand a live demo every two weeks.
- Keep the code in your own repository from day one.
- Tie milestones to working features, not documents.
Add two more. Write acceptance criteria for each milestone before work on it starts, so “done” is never a negotiation. And agree the change-request process at the start: who can raise a change, how it is estimated, and that nothing outside the agreed scope is built until you have approved its price.
Questions to ask any vendor before you sign
- What happens to the price if your estimate is wrong?
- What exactly will the discovery phase produce, and do we own it if we stop there?
- How are milestones defined, and what do we see at each one?
- How are scope changes estimated and approved?
- Where does the code live, and who owns the IP?
- What support is included after launch, and what does it cost afterwards?
A good vendor answers each in a sentence. For AI work specifically, we have written a fuller checklist on how to evaluate an AI agent development company.
The same buy-or-commission logic applies before any contract is signed. Sometimes the cheapest fixed price is no build at all; our build vs buy analysis for affiliate tracking shows that comparison on one product category, and our web app development page shows how we scope custom web builds when building does win.
Sources
- Delivering large-scale IT projects on time, on budget, and on value, McKinsey & Company with the University of Oxford
- Why Your IT Project May Be Riskier Than You Think, Flyvbjerg & Budzier, Harvard Business Review (2011), via arXiv
- FAR 16.202-1: Firm-fixed-price contracts, Acquisition.gov
- FAR 16.601: Time-and-materials contracts, Acquisition.gov
Web App Development
High-performance SaaS products, portals, dashboards and marketplaces, with clean architecture, fast UX and the integrations your business runs on.
