Fixed priceTime and materialsContractsBudgetIT leadership
Fixed price vs time and materials for software development
7 min read
A fixed-price contract buys a defined result for an agreed amount, so the vendor carries the risk of overruns; time and materials buys working time, billed by the hour or day, so the client carries that risk. Fixed price suits a scope that can be closed before coding starts; time and materials suits ongoing work steered by an in-house product owner.
Both models are legitimate. They simply do not buy the same thing, and they do not put the risk in the same place. Here is how to choose, and how to make a fixed price hold when you pick one.
Two contracts, two different things bought
Time and materials buys capacity
With time and materials (often shortened to T&M, and close to what is called staff augmentation when people are placed in your team), you buy production capacity: one or more profiles, billed by the hour, day or month, working under your direction. The vendor commits to skills and availability, not to an outcome. You set priorities, arbitrate features, organise testing and decide when the product is finished.
This model makes real sense in one specific case: you already have technical leadership and an established product vision, and you want to extend an existing team over a long period. T&M is then reinforcement, not outsourcing.
Fixed price buys a result
With a fixed price, you buy a defined product for an agreed amount. The vendor commits to the scope, the schedule and the price, and takes care of organisation, technical choices and contingencies. If development takes twice as long as planned, that is the vendor's problem, not your invoice.
A fixed price therefore requires one non-negotiable condition: the scope must genuinely be closed before pricing. Otherwise the vendor protects itself with a margin you pay for, or with change requests you discover along the way.
Side by side
| Fixed price | Time and materials | |
|---|---|---|
| What you buy | A defined result | Working time |
| Who carries overrun risk | The vendor | The client |
| Budget certainty | Known before coding | Known at the end |
| Flexibility during the project | Changes go through a change procedure | Priorities can change every week |
| Who steers day to day | The vendor, against an agreed scope | The client |
| Effort required from the client | Concentrated at the start (scoping, validation) | Continuous (steering, arbitration, testing) |
| Best for | A business need with known rules and users | Products still searching for their market, or team extension |
| What remains at the end | A delivered, deployed product | Code, and the people leave when the contract ends |
Where the risk goes
This is the only question that really matters, and it fits in one line: with time and materials, the risk of overrun stays with the client; with a fixed price, it moves to the vendor.
That transfer has a price, and it is legitimate. A company committing to a firm amount must cover the uncertainty left after scoping. The better the scoping, the smaller that margin, until it becomes marginal once the scope has been closed on something visible rather than on a text open to interpretation.
With time and materials, the absence of an apparent margin is paid for elsewhere. Steering falls to your managers, often people for whom it is not the main job. Functional trade-offs happen in meetings rather than in a contract. And above all, the meter only stops when someone decides to stop it.
Three questions that settle the choice
Who decides what "finished" means? If nobody in your organisation has the time and the mandate to make decisions every week, time and materials will produce a project that drags on. A fixed price forces that decision upfront, once, when it is cheapest to make.
How long will the need stay stable? A need that changes every two weeks by nature, such as a platform still looking for its market, fits poorly with a firm commitment. An identified business need, with known rules and users already in place, prices very well.
What happens at the end? With time and materials, when the engagement stops, you are left with code and nobody to run it. With a fixed price, hosting, monitoring and future changes are discussed in the contract, at the same time as everything else.
Signs of a fragile fixed price
A fixed price has a bad reputation in some organisations, for a good reason: badly scoped, it produces exactly what it is blamed for. A vendor pricing on open-ended specifications will deliver the cheapest reading of every ambiguous sentence, then bill the rest as change requests. The client thinks they bought a fixed price; they bought a starting point for negotiation.
The warning signs are easy to spot:
- the quote arrives very fast, with no scoping workshop;
- the scope is a list of features with no screens;
- the contract talks about person-days rather than deliverables;
- nobody has yet seen what the application will look like.
How to make a fixed price hold
- Close the scope on something visible. A prototype with the screens, journeys and realistic data removes most interpretations. What is on screen is in the price.
- Describe deliverables as usable results, not as hours or documents: "a technician can record and submit a job sheet from a phone", not "mobile module, 15 days".
- Agree on the change procedure before signing. Any request outside the scope is priced, decided, then accepted or postponed. Nothing is added silently.
- Deliver in usable stages. Each stage is something your teams can use and validate, which detects misunderstandings while they are still cheap.
- Price the life after launch. Hosting, monitoring and changes belong in the same discussion as the build.
Hybrid models
Real projects often combine both logics. Two patterns are common:
- Discovery, then fixed price. A short, bounded phase clarifies the need, then the build is contracted at a fixed price on the resulting scope.
- Capped time and materials. Hours are billed, but up to a ceiling that cannot be exceeded without a new decision.
Both are reasonable. The first is the closest to what we do, except that our discovery phase is a free prototype rather than a paid workshop.
Our position: no time and materials
LPR Studio does not sell hours or people. This is not a commercial pose but a consequence of how we work: we deliver a finished, deployed and maintained product, and that commitment only makes sense if we carry the risk of building it.
Our three models all rest on a result. Fixed-price development starts from the prototype we validated together and runs to the deployed product. The subscription model goes further: you do not pay for the development, only a monthly subscription covering hosting, maintenance and updates, which means we remain the publisher and operator of the application. Our SaaS products, finally, are applications we run for many customers.
What that product costs, and what makes the price move, is covered in our article on the cost of a custom business application.