Fixed Price vs Time and Materials for Software Projects
ยท 7 min read
Fixed price suits work whose scope is clear enough to write down and test: the vendor carries the risk of overrunning and charges for it. Time and materials (T&M) suits work whose scope will change as you learn: the client pays for the hours actually spent and keeps the right to steer. Since most software projects begin unclear and get clearer, a common approach is to fix the price of a discovery and a well-defined first phase, then move to T&M once the product is live and changing.
This article is practical guidance, not legal advice. Have a lawyer review any contract you sign.
The two models in one table
| Fixed price | Time and materials | |
|---|---|---|
| What is agreed | A scope, a price and usually a date | Rates, a team and a way of working, often with a budget cap |
| Who carries the overrun risk | Mainly the vendor, up to the agreed scope | Mainly the client |
| How change is handled | Change requests, each priced and approved | Re-prioritise the backlog; the cost follows the hours |
| What the client must provide | A clear scope up front and quick sign-off | Ongoing time from a product owner who makes decisions |
| Price includes | The work plus a risk margin | The work as it happens |
| Works best when | Scope is defined and testable | Scope is uncertain or expected to change |
| Typical failure | Disputes over what was "in scope" | Budget drift without visible progress |
The table hides one important point: a fixed price does not remove risk, it prices it. A vendor quoting a fixed price on a vague scope will either add a large margin or lose money and try to make it back through change requests. Both are worse for the client than an honest range.
When fixed price works
Fixed price works when someone could hand the scope to a different team and get roughly the same thing built. In practice that means:
- Requirements are written and testable, with acceptance criteria for every Must.
- The integrations are known: the APIs exist, are documented, and someone has checked them.
- The assumptions are listed, so both sides know what the price relies on.
- The client can review and accept work quickly. A fixed price with slow sign-off becomes a delay dispute instead of a scope dispute.
US federal acquisition rules offer a useful reference point here, even outside government work. They steer firm-fixed-price contracts toward work that can be bought on "reasonably definite functional or detailed specifications", and they allow time-and-materials only when the extent or duration of the work cannot be estimated with reasonable confidence at the start (FAR Part 16). Commercial software contracts are not bound by these rules. The logic still carries over: price firmly what you can specify, and pay for time where you cannot.
Good fixed-price candidates: a discovery phase itself (time-boxed, with defined deliverables), a clickable prototype, a migration with a known source and target, or a first release whose scope came out of a proper discovery.
When time and materials works
T&M works when the job is to find the right product as much as to build it:
- The product is new, and user feedback will change the backlog.
- Integration or data quality is unknown until someone looks inside the systems.
- The work is ongoing: improvements, maintenance, a product team after launch.
- The client has a product owner who can prioritise every week.
The risk with T&M is not price. It is drift. Without a goal per sprint or milestone, a cap and visible output, hours pile up and nobody can say what they bought. Typical safeguards:
- A not-to-exceed budget per phase or per month, with a warning at 75-80% of it.
- Milestones with low-high estimates, so the client can see whether spend matches progress.
- Regular demos of working software, not status reports.
- A right to stop at the end of each phase, with the work done so far handed over.
The federal rules make the same point: T&M orders there need a ceiling price, and contracting officers are told to avoid protracted use of T&M once experience gives a basis for firmer pricing (FAR Part 16). In other words, T&M is meant to be a phase, not a permanent state.
The hybrid after a discovery phase
The discovery phase is what makes a fixed price possible. Before it, scope is a wish list. After it, you have requirements with priorities, an architecture, a roadmap with estimated milestones and a list of assumptions. That is enough to fix the price of a first phase, but rarely enough to fix everything.
A common structure:
| Phase | Model | Why |
|---|---|---|
| Discovery | Fixed price, time-boxed | Deliverables are known in advance; the client gets a plan whether or not they go ahead |
| Phase 1 (first release) | Fixed price, or T&M with a cap | Scope comes straight from discovery; assumptions are written into the contract |
| Later phases | T&M with a monthly budget | The product is live, feedback changes priorities, and fixing the scope would mean pricing guesses |
Two details decide whether the hybrid holds:
- The assumptions travel into the contract. If phase 1 is priced on "the client's API returns stock levels in real time", say so, and say what happens if it does not.
- The estimate is a range, and the fixed price sits inside it on purpose. Discovery gives you a low-high range per milestone. Where the price sits in that range, and why, should be visible to both sides.
Here is what that input looks like in the Discovery Phase AI example report, made for an invented project called Fieldwise: four milestones, each with a person-week range, a 16-22 person-week total, and the assumptions that range depends on.
Risks for each side
| Risk | Fixed price | Time and materials |
|---|---|---|
| For the client | Paying a risk margin; arguing over what "in scope" meant; a vendor cutting corners to protect margin | Open-ended cost; paying for the vendor's learning; slow progress if the product owner is unavailable |
| For the vendor | Absorbing overruns; scope creep through vague requirements; slow client sign-off eating into margin | Being cut off at short notice; budget caps used as fixed prices in disguise; disputes over productivity |
| Shared | A bad scope document makes both models fail, just differently |
A cap on a T&M contract is often treated as a fixed price in all but name, while the vendor still carries no obligation to finish. Be clear which one you mean. A cap is a stop-and-review point, not a promise of delivery.
How to choose
Ask four questions, in order:
- Could you write acceptance criteria for every Must today? If not, the scope is not ready for a fixed price. Run or finish a discovery first.
- Are the integrations and data known? If a key system has not been looked at, either fix the price of everything except that part or treat it as T&M until it is understood.
- Who will make decisions every week? T&M without an available product owner is the most expensive option on this list.
- Is the product expected to change after launch? If yes, plan for T&M after the first release whatever you choose for it.
As a rule of thumb, not a formula: if you answered "yes, yes, someone named, no" you can fix the price. Two or more "no" or "not sure" answers point to T&M with a cap, or to a fixed-price discovery that turns those answers into "yes".
A discovery that produces requirements with acceptance criteria, an estimated roadmap and a written list of assumptions is what makes either model safe. The discovery phase checklist lists what to have before you sign, and the discovery phase in software development explains what that phase produces.