Buyers prefer fixed price because it feels like certainty. Vendors accept it and price in the risk, then defend the scope line vigorously because their margin depends on it. Both parties then spend the project arguing about whether a request is a clarification or a change, which is a poor use of everyone's attention.
01What fixed price actually does
It transfers estimation risk to the vendor, and the vendor charges for accepting it - typically a substantial premium over their expected cost. You are buying insurance, and like all insurance it is priced above the expected loss because the seller must survive the bad cases.
It also changes behaviour. Once the price is fixed, every request is evaluated against margin rather than against value. That is not vendor bad faith, it is the incentive the contract creates, and it is why fixed-price projects generate change requests over things that would be five-minute conversations under a different model.
| Fixed price | Time and materials | |
|---|---|---|
| Budget certainty | High, if scope holds | Low without a cap |
| Scope flexibility | Low, changes are contractual | High |
| Vendor incentive | Minimise effort within scope | No efficiency incentive |
| Requires from buyer | Detailed upfront specification | Active engagement throughout |
| Risk premium paid | Yes, embedded in the price | No |
| Fits | Well-understood, stable scope | Discovery, evolving requirements |
02Where fixed price genuinely works
A migration with a known source and target. A well-specified integration. A rebuild of an existing system whose behaviour is documented and observable. In each case the unknowns are small enough that the risk premium is modest and the specification can be genuinely complete.
The common thread is that someone can write down what done means without hand-waving. Where that is possible, fixed price is a reasonable purchase and the premium is worth the certainty.
03Where it reliably goes wrong
New product development with genuine uncertainty. Anything where the requirements will be informed by what users do with the first version. Anything involving a legacy system whose behaviour nobody has fully documented, which describes most legacy systems.
In those cases fixed price produces one of two outcomes: an enormous risk premium that makes the project poor value, or a vendor who under-priced and now must defend scope aggressively to avoid a loss. Neither produces good software, and the second produces a difficult relationship.
| Situation | Model | Why |
|---|---|---|
| Data migration, known systems | Fixed price | Scope is genuinely definable |
| New product, uncertain requirements | T&M with a cap | Scope will change as you learn |
| Ongoing development | Dedicated team | No meaningful scope boundary |
| Legacy modernisation | T&M, phased | Unknowns emerge continuously |
| Discrete integration | Fixed price | Clear inputs, outputs and done |
04The structures that work better than either
Capped time and materials gives the buyer a ceiling and the vendor no incentive to pad, with the agreement that work stops at the cap for a conversation rather than continuing on hope. It is the most common structure among teams that have done this several times.
Fixed-price discovery followed by an informed estimate is the other. Two to four weeks, fixed, producing a technical plan and a defensible estimate for the build. Both parties then decide with real information, and the buyer owns the artefact regardless of who does the work.
05The question that predicts the outcome
Ask a prospective vendor what happens when you want something that was not in the specification. A vendor who says every change goes through a change request is describing a project you will find frustrating. One who says small things get absorbed and material ones get discussed is describing a working relationship.
Then ask what happens if they finish early. Under fixed price the honest answer is that they keep the difference, which is fine and worth knowing. Under time and materials you stop paying, which is also fine. Contracts where neither party can answer that question clearly are the ones that produce disputes.
Topics
Lena Voss
Lead Architect · SyncTrix
Writes about the engineering decisions behind production systems - architecture, delivery and the trade-offs that only show up at scale.
Building something like this?
SyncTrix engineers AI, SaaS, platform and cloud systems for enterprises and high-growth teams. Tell us what you're shipping and we'll scope it with you.
Talk to an engineer