Fixed price or time & materials? How to buy custom software without overruns

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 — integrations, data, 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.

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.

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, and a breakdown of AI agent development cost by agent type.