Underneath every pricing model is the same question: who pays when the work turns out to be bigger than either side thought?
That is worth stating plainly, because pricing discussions usually happen in the language of trust and value, and the actual subject is risk allocation. Software estimates are uncertain — not because estimators are careless, but because the size of the work depends on details that are not visible until you are inside it. A pricing model is an agreement about who absorbs that uncertainty.
There are three common answers, plus one arrangement worth avoiding.
Fixed price
You agree a scope and a number. The supplier delivers that scope for that number regardless of how long it takes.
Who carries the risk. The supplier, formally. In practice it is shared, because a supplier losing money on a project makes decisions that affect you.
What it optimises for. Certainty about the invoice, and a strong shared incentive to define scope precisely before starting.
Where it works. Well-understood work with a stable definition of done. A marketing website with an agreed page list. A migration between two systems you have both examined. A defined integration. Anything where an experienced supplier has done something close enough before to know the shape.
Where it fails. Any project where the requirements will be discovered during the build, which includes most first-time custom software.
The failure is worth describing because it is not obvious from the contract. Once the price is fixed, every change becomes a negotiation, and both sides begin behaving accordingly. You stop raising improvements because raising them starts a conversation about cost. The supplier starts reading the specification narrowly, because a generous reading comes out of their margin. Within two months the project has a defensive character: two parties working from a document rather than towards an outcome.
There is also the pricing effect. A supplier quoting a fixed price on uncertain scope must include contingency for the worst plausible reading. You pay that contingency whether or not the risk materialises, which means fixed price on uncertain work is typically the most expensive of the three models, not the safest.
Time and materials
You pay for the time spent, at agreed rates, usually with a forecast and regular reporting.
Who carries the risk. You.
What it optimises for. Flexibility, and honest pricing of uncertainty. Nobody is charging you contingency for risks that did not happen, and nobody is defending a specification they now know is wrong.
Where it works. Genuine product development where the direction is refined as you learn, ongoing improvement after launch, and any project where the priorities will change during the build.
Where it fails. When there is no discipline around it. Time and materials without a forecast, a cadence of review and a clear objective is an open budget, and open budgets drift — not usually through dishonesty, but because a project without a stated definition of done will keep finding worthwhile things to do.
Three conditions make it safe: a capped forecast per stage that triggers a conversation rather than an invoice surprise; something usable delivered at short intervals so progress is visible rather than reported; and a written objective that lets either side say a proposed piece of work does not serve it.
Staged, with a fixed price per stage
The middle position, and the one that fits most custom projects. The work is broken into stages. Each is priced fixed once its scope is understood, and the next is not priced until the previous is done.
Who carries the risk. It is divided. Each stage's risk sits with the supplier; the risk that more stages are needed sits with you.
What it optimises for. Predictable commitments in the short term without pretending to certainty about month six.
Where it works. Most custom software. It fits how these projects actually behave: understanding improves as you go, and a price given after understanding is far better than one given before it.
Where it fails. When stages are drawn badly. If stage one produces nothing you can evaluate, the model has the costs of both approaches and the benefits of neither.
The important property is that every stage boundary is a genuine exit. You should be able to stop after any of them holding something of value: a document you could take to another supplier, or working software that does part of the job. If a stage boundary does not offer that, it is not a stage, it is an instalment.
Comparing them
| Fixed price | Time and materials | Staged | |
|---|---|---|---|
| Risk sits with | Supplier, priced into the number | You | Divided by stage |
| Best when | Scope is genuinely known | Direction will be refined as you learn | Understanding improves as you go |
| Typical total cost | Highest on uncertain work, because of contingency | Lowest if managed, highest if not | Middle, and the most predictable |
| Response to change | A change request and a negotiation | Reprioritise within the forecast | Absorbed within a stage, or scheduled into the next |
| What you need to bring | A precise, stable definition of done | Active involvement and a clear objective | Decisions at each stage boundary |
| Main failure mode | Defensive reading of the specification on both sides | Drift with no definition of done | Stages that produce nothing you can judge |
| Where to be careful | Anything vague in the scope will be read narrowly | The absence of a cap and a review rhythm | Whether you could genuinely stop at each boundary |
The arrangement to avoid
Fixed price on an undefined scope. It appears in a specific form: a supplier gives a firm number based on a short conversation, without a written scope, and both parties are pleased with how quick it was.
There is no version of this that ends well. Either the supplier absorbs the gap, resents it, and the quality reflects that, or you receive a series of change requests for things you assumed were included. The disagreement is not caused by bad faith. It is caused by there being no shared document defining what was bought.
If a supplier is willing to name a firm price without examining the process, that is information about how the project will be run, not a favour.
What to look for in the contract, whichever model
The model matters less than four clauses that hold regardless.
- What is excluded. Hosting, third-party licences, content creation, data migration, training, support after launch. Exclusions are where quotes stop being comparable.
- How changes are handled. Every project has changes. The question is whether there is an agreed, unremarkable mechanism, or whether each one becomes an event. Look for a small, defined process rather than a formal one.
- What counts as done. Acceptance criteria, agreed in advance, in language you could check yourself. "Delivered" and "working" are different words and the gap between them is where final invoices get disputed.
- What happens at the end. Who holds the code, the accounts, the domain and the data, and what you receive at handover. This matters most on the day the relationship ends, which is exactly when it is too late to negotiate.
Payment schedules also deserve a look. Some money up front is normal and reasonable. A schedule weighted heavily to the start removes the supplier's incentive at precisely the stage where the difficult work happens, and one weighted entirely to the end asks a small supplier to finance your project, which affects who can bid.
Comparing quotes written on different models
This is the practical problem: one supplier quotes a fixed price, another quotes a daily rate with an estimate, and the numbers are not comparable.
Reduce them to the same three questions.
What am I committed to today? The fixed price commits you to the whole number. The staged quote commits you to stage one. Time and materials commits you to whatever notice period the contract specifies. These are very different commitments and they are the first thing to line up.
What is the realistic total? For time and materials, ask for a forecast range and what would push it to the top of that range. For fixed price, ask what is excluded and what a typical change costs. For staged, ask what the remaining stages are expected to cost, understanding it is an estimate.
What happens if we are wrong about something important? This question separates suppliers more reliably than any other. You are listening for a specific mechanism rather than reassurance.
An illustrative example
A company needs two things: to replace a public website, and to build an internal tool for a process nobody has documented.
Pricing both the same way is the mistake. The website has a knowable scope, being a page list, content and a design direction, and suits a fixed price comfortably. The internal tool does not: its shape depends on a process that has to be examined before it can be described.
The sensible arrangement prices them differently. Fixed price for the website. For the tool, a fixed-price discovery stage producing a scope document, then a fixed price for the build once that document exists. The client gets certainty where certainty is available and avoids paying contingency where it is not. Hypothetical, but a common enough shape that it is worth recognising.
Common questions
Which is cheapest? Time and materials, if the project is well run and you are actively involved. Fixed price is the most expensive on uncertain work, because you pay for contingency regardless. Staged sits between and is the most predictable, which is often worth more than being marginally cheaper.
Can I ask for a fixed price after a discovery stage? Yes, and it is a reasonable expectation. That is precisely what discovery is for. Insist that the output is usable by any supplier, not written so that only the author can build from it.
What about retainers? Sensible for continuous improvement after launch, where there is a real flow of work. Less sensible as an open commitment with no defined output. Ask what happens in a month with nothing to do, and whether unused time carries forward.
Is an hourly rate a useful comparison between suppliers? On its own, no. Rate multiplied by hours is what you pay, and a higher rate that takes half the time is cheaper. Rates are comparable only alongside a demonstrated pace of work, which is difficult to assess in advance — which is one more reason to start with a small, real, paid stage rather than a large commitment.
The short version
- Every pricing model is an agreement about who pays when the work is bigger than expected.
- Fixed price suits genuinely known scope. On uncertain work it is usually the most expensive option and makes both parties defensive.
- Time and materials is honest about uncertainty and needs three things to stay safe: a forecast cap, a short review rhythm, and a written objective.
- Staged, fixed per stage, fits most custom software. Each boundary must be a real exit with something of value in your hands.
- Avoid a firm price given without a written scope. It has no good ending.
- Four clauses matter more than the model: exclusions, how change is handled, what counts as done, and what you get at the end.
Where to take this next
If the quotes in front of you differ by more than you expected, the reasons are usually in what drives the cost of custom software rather than in the rates.
If you are choosing a model for a project that has not been scoped yet, the honest answer is that it cannot be chosen yet, and how to write a project brief a developer can actually price is the step that makes it choosable.
We are happy to look at a set of quotes and tell you where they differ. Discuss your idea.
# Visual recommendations
Concepts only. Hairline drawing, ink and brass.
Hero visual — where the risk sits
Concept. Three horizontal bars, one per model, each divided between two ends labelled you and supplier. Fixed price is weighted almost entirely to the supplier end, with a hatched section at the client end labelled contingency you pay regardless. Time and materials is weighted to the client. Staged is divided into four segments, alternating, showing risk transferring at each boundary.
Purpose. Makes the article's opening claim visible immediately: these are risk arrangements, not just payment arrangements.
Alt text. Three pricing models shown as bars dividing risk between client and supplier: fixed price sits mostly with the supplier but includes contingency the client pays regardless, time and materials sits with the client, and staged alternates at each boundary.
Supporting visual — a stage boundary as an exit
Concept. Four stage blocks left to right, with a small door drawn at each boundary. Under each door, a label naming what you would be holding if you left there: a scope document, a structure and designs, a working first release, the complete system. A fifth block drawn with a dashed outline and no door, labelled not a stage — an instalment.
Purpose. Carries the article's strongest practical test, which is otherwise buried in prose.
Placement. In the staged pricing section.
Alt text. Four project stages, each with an exit showing what you would hold if you stopped there, next to a dashed block representing a payment milestone that produces nothing you could take away.