Most arguments about software pricing are really arguments about who carries the risk when the estimate turns out wrong. Each model puts that risk in a different place.
Fixed price
The supplier quotes one number for an agreed scope, and that is what you pay. If the work takes longer than estimated, the supplier absorbs it.
- Good for: a well-defined MVP, a website rebuild with a known page list, an integration between two documented systems.
- What you get: budget certainty, which matters when you are spending a fixed amount of investment or an approved budget.
- What it costs you: flexibility. Anything outside the agreed scope becomes a change request, priced separately. And a sensible supplier builds contingency into the number, so on well-understood work you may pay a little more than time and materials would have cost.
Time and materials
You pay for the time spent, at an agreed rate, usually invoiced weekly or monthly, often against an estimate or a cap.
- Good for: exploratory products, work where user feedback will change the plan, ongoing development after launch, and anything involving a system nobody has fully documented.
- What you get: the freedom to change direction as you learn, and no padding for risks that never happen.
- What it costs you: certainty. The final number depends on decisions you have not made yet, so you need visibility into progress to stay in control.
Where the risk sits
| Fixed price | Time and materials | |
|---|---|---|
| Who carries estimate risk | Supplier | You |
| Cost certainty | High | Lower, controlled by caps |
| Changing direction | Change requests | Built in |
| Contingency in the price | Usually | None |
| Needs from you | A clear scope up front | Regular decisions |
How to tell which one suits your project
- Can you write down what "done" looks like? If you can describe every screen and integration today, fixed price is realistic. If you cannot, a fixed price is a guess with a contingency on top.
- Will users change the plan? If you are building to learn, you will want to act on what you learn without renegotiating.
- Is the budget fixed? Time and materials with a cap and a prioritised backlog gives you a fixed ceiling without a fixed scope.
- How much of the work depends on systems you do not control? Third-party integrations are where estimates break.
The hybrid that often works best
Split the project. A short discovery and prototype phase, priced as a fixed piece of work, turns unknowns into a written scope and a clickable design. Once that exists, the build can be priced as a fixed project with confidence, or run on time and materials with a well-understood backlog. You are not asked to fix a price on something nobody has defined yet.
Whichever model you choose, insist on two things: working software you can see during the build, not only at the end, and documentation that lets someone else take the code over.