Why the fixed-price software quote stops working on a living product

You sign for A, B and C. Three weeks later, A is no longer the priority, B needs rethinking, and you have just worked out that D was the real subject. The quote has not moved.

That gap is not bad luck. It is the mechanical consequence of a tool designed for stable scopes, applied to something that is not stable. A digital product learns as it goes: every delivery changes what you know about your users, and therefore what deserves to be built next.

So the problem is not that quotes are dishonest. It is that they answer a question you stop asking once the product has launched: "what exactly does this list cost" rather than "how do I move fast without going back through negotiation".

When a priority changes, the bill for that change rarely shows up on the bill. It shows up elsewhere, which is what makes it hard to defend internally.

First there is the delay. Between the moment you express the new need and the moment someone writes the first line of code, it has to be requalified, re-estimated, approved and replanned. None of those steps produce anything, and together they often take longer than the change itself.

Then there is the effect on the relationship. Every amendment turns a product conversation into a commercial negotiation. You stop saying "this would be better this way" and start calculating whether it is worth asking. That is the moment a client stops sharing ideas, and it is a dead loss for both sides.

Finally there is the anchoring effect. A written scope becomes a moral reference: anything outside it looks like an unreasonable request, even when it is the best idea of the quarter.

It would be easy to make quotes the villain. That would be dishonest, because a quote provides a real service, and it provides it to you rather than to the provider.

A quote transfers overrun risk. If the provider underestimated the work, they absorb the gap. You paid a price, you get a result, and the bad surprise belongs to someone else. No time-and-materials arrangement and no subscription offers you that guarantee.

“A quote sells you certainty about price. A subscription sells you certainty about pace. Those are not the same need.”

So the question is not which of the two is good, but which one matches your situation right now. Many companies need both in sequence: a package to build and launch, a subscription to keep it alive.

Refusing fixed-price work on principle is expensive. Here are the cases where you should ask for it, and where a provider pushing you towards a subscription is doing you a disservice.

Outside those three cases, ask yourself honestly what the quote gives you, and what it costs you in speed of decision.

If the list cannot be frozen, then do not buy a list. Buy production capacity and keep control of the order in which you consume it.

Neither column beats the other. The left one protects you from overrun, the right one protects you from paralysis. You are choosing which risk you would rather carry.

This shift closely resembles the one separating an MVP from a V1: in both cases you stop describing the destination and start describing the next step.

If you are halfway through a fixed-price engagement that no longer fits, there is a clean way out, and it does not involve a standoff.

Finish the batch in progress rather than cutting it short. A half-finished build is worth nothing to anyone and leaves technical debt that someone will pay for. Then propose switching the rest: whatever has not started goes back into a priority queue instead of staying inside a signed scope.

A provider who refuses that conversation is telling you something useful about what comes next. A provider who accepts it is showing you that their model rests on what they deliver, not on what they got you to sign.

The fixed-price project is not dead and will not be. It is simply misapplied when used on a product that learns, and that has become the majority situation.

So the right question to ask a provider is not "what does this project cost", but "what happens the day I change my mind". The answer to that question tells you everything the quote itself will not.

“A well-chosen contract makes changing your mind free. A badly chosen one makes it expensive, and eventually you stop changing your mind.”

Two articles to go further: unlimited development subscription and choosing your technical partner.