Fixed Price Software Development: When It Works and When It Blows Up
A client asks for a fixed price. The vendor writes a spec, quotes a number, and both sides sign it feeling like they’ve eliminated risk. Six weeks in, the client wants a feature that wasn’t in the spec, the vendor calls it a change order, and the relationship that started as a handshake is now a negotiation over what “originally scoped” meant. That’s not a fixed price project gone wrong. That’s what most fixed price projects actually look like once real requirements meet a document written before anyone had built anything.
Why clients ask for it anyway
The appeal is real, not irrational. A fixed price gives a budget owner a number they can put in front of a CFO, a board, or their own boss, and defend without hedging. It shifts estimation risk onto the vendor, at least on paper. For a client who’s been burned by an open-ended time-and-materials engagement that ran three times over budget with no one accountable for the overage, fixed price feels like the disciplined choice.
The problem is that software isn’t a fixed, fully-specified good at the point most contracts get signed. A construction contract can fix a price because the blueprint is (mostly) complete before anyone pours concrete. A software spec written before development starts is closer to a hypothesis about what will work than a blueprint. Requirements that look complete in a document turn out to have gaps, ambiguities, and outright contradictions once a developer tries to build against them.
What actually happens to the risk
Fixed price doesn’t remove risk from a project. It moves it, and where it lands depends on who wrote the spec and how well.
If the spec is genuinely thorough and the vendor has built similar systems before, risk sits with the vendor, and a good vendor prices that risk into the number, padding for the unknowns they can already see coming. If the spec is thin, ambiguous, or was written by someone who hasn’t scoped software before, the risk doesn’t disappear. It resurfaces later as change orders, scope disputes, or a vendor quietly cutting corners on quality to hit the number they committed to. That last outcome is the one nobody wants but almost nobody prices for: a vendor under margin pressure on a fixed bid has every incentive to ship the minimum that technically satisfies the spec, not the thing the client actually needed.
Where fixed price genuinely works
It’s not a bad model everywhere. It works well when the scope is narrow, well-understood, and low in novelty: a WordPress theme customization, a known integration between two systems with documented APIs on both sides, a data migration with a clearly defined source and target schema. In these cases the unknowns are small enough that a competent team can estimate accurately, and the client isn’t relying on discovery to happen during the build.
It also works for a discrete, bounded phase of a larger engagement rather than the whole thing. Fixed-price the discovery and design phase, deliver a real spec and prototype from that phase, then fixed-price (or time-and-materials) the build against a spec that’s now been validated instead of guessed at. This is the compromise that shows up most often in mature dev shops, because it keeps the certainty clients want without pretending the first estimate was ever going to be accurate.
Where it breaks down
Anything with meaningful product discovery baked into it: a new product, a system integrating with a partner API that hasn’t been fully documented, a UX that needs user testing to get right. In these cases the client is essentially asking the vendor to fix a price on a moving target, and the vendor’s only rational responses are to pad the estimate heavily, interpret every ambiguity in their own favor, or lose money. None of those outcomes serve the client well, whichever one the vendor picks.
Long timelines make this worse. A six-month fixed bid is pricing against six months of market conditions, technology changes, and the client’s own evolving understanding of what they need, all locked in on day one. The industry’s own change-order data backs this up consistently: fixed-price projects longer than a few months see change requests at a rate that erodes most of the certainty the model was supposed to provide in the first place.
Making a fixed price contract actually work
Write the spec at a level of detail that would let a third-party developer, not just the two parties who negotiated it, build the same thing from it. Vague specs are where disputes live. Define what’s explicitly out of scope, not just what’s in it — a line like “does not include payment processing integration” prevents more arguments than ten pages describing what is included.
Build a change-order process into the contract itself, with a pre-agreed rate for scope additions, rather than negotiating it from scratch mid-project when both sides are already frustrated. And build in an acceptance criteria section that’s testable, not descriptive: “the checkout flow supports Visa, Mastercard, and Amex via Stripe, and rejects declined cards with a visible error message” beats “the checkout flow should work smoothly,” because the second one is where post-delivery disputes are born.
Fixed price isn’t the villain here, and neither is time-and-materials. The mismatch is between a contract model that assumes certainty and a discovery process that hasn’t happened yet. Match the model to how much is actually known at the point the contract gets signed, and most of what makes fixed price painful stops being a surprise.