Fixed Price vs Time and Materials vs Outcome-Based Contracts
The UK Cabinet Office tells its own buyers: fixed price only works with fixed scope. Almost no genuinely new software has fixed scope. Here is what that means for how you should actually pay.

The UK Cabinet Office buys more technology than almost any organisation in the world, and its own guidance to its own buyers states the underlying principle bluntly:
"The key component of fixed price has to be 'fixed scope'. Floating or variable scope is not suitable for fixed pricing."
(Cabinet Office risk allocation and pricing guidance)
Most genuinely new software does not have fixed scope, because you learn things as you build it. That single fact should decide most of your contract-structure decisions, and it usually doesn't.
Fixed price
You pay one number for a defined scope. It works well when the scope really is fixed — a known integration, a well-specified migration, a feature whose behaviour is fully documented in advance.
It works badly, predictably, when scope is uncertain. The supplier has priced their risk into the number one way or another: either a premium for the uncertainty you might not encounter, or no premium at all, in which case the first real surprise becomes a commercial dispute rather than a technical conversation. The UK National Audit Office traced exactly this failure mode across five large government programmes, finding at least 29 years of delay and over £3 billion in cost increases, driven by frameworks "geared to buying inputs rather than outcomes." (NAO, January 2025)
Time and materials
You pay for hours worked. It is honest about uncertainty — nobody is pretending to have priced a risk they can't actually estimate — but it puts all of the schedule and budget risk on you, the buyer, and provides no natural incentive for the supplier to finish efficiently.
It works well with a trusted, transparent supplier and active client-side oversight. It works badly with a supplier who benefits from the meter running and a client too busy to check.
Outcome-based contracts
You pay for a defined result rather than either a fixed scope or hours worked — a working integration, a measured reduction in processing time, a system that passes a specific acceptance test. This aligns incentives more cleanly than either alternative, but it requires you to be able to define and measure the outcome precisely, which is its own significant discipline.
The US government's clearest recent statement of good practice, OMB M-25-22, requires exactly this kind of rigour for federal AI contracts: agencies must be able to evaluate supplier performance on a defined cadence, and evaluation data "should not be accessible to the vendor." (OMB M-25-22) That is a workable model for private contracts too, not just federal ones.
How to actually choose
Match the contract to how well-defined the work is, not to which model feels safest.
Scope genuinely fixed and well-documented? Fixed price is reasonable, and cheaper than paying a risk premium for uncertainty that doesn't exist.
Scope will evolve as you learn? Time and materials with milestone checkpoints, or an outcome-based structure if you can define the outcome precisely enough to measure it.
Can't yet tell which one you're in? That itself is informative — it usually means a short, fixed-price discovery phase should come first, specifically to convert an unknown scope into a known one before you commit to a pricing model for the build.
The worst outcome in this category isn't picking the wrong model. It's picking a fixed price for genuinely uncertain scope, because that's the version where nobody involved was dishonest and the project still fails.
Kaizen Spark Tech designs and delivers software, AI, automation and digital infrastructure for businesses and institutions. Every statistic here is linked to its original published source.
