Why we stopped selling fixed-price MVPs

Why we stopped selling fixed-price MVPs

A fixed price sounds like the client carrying less risk. It is usually the opposite. What a fixed price actually does is move every disagreement about scope from the build into the invoice, and it does that at the worst possible moment: after the money is spent and before the product works.

We sold fixed-price builds for years. We stopped, and this is the reasoning rather than a policy announcement.

A fixed price is a bet on a specification nobody has read carefully enough

To quote a whole product up front, someone has to believe the specification is complete. It never is. Not because clients write bad specs, but because a spec is a description of a thing that does not exist yet, written before anyone has touched the parts that turn out to matter.

The integration that is one line in the document is three weeks of work against an API that returns different shapes for the same call. The 'simple' admin screen is where the actual business logic lives. Neither is anybody's fault. Both are invisible until you build.

Once a fixed price is signed, that discovery becomes adversarial. Every unknown is now a negotiation about whether it was in scope. The supplier is arguing to protect a margin, the client is arguing because they thought they had bought a working product, and both of them are right.

The incentives point the wrong way for everyone

Under a fixed price the cheapest way for a supplier to finish is to do less. Not maliciously: the pressure is structural. Every hour spent on error handling, on the empty state, on the migration that runs correctly the second time, is an hour spent against a fixed number. The parts of software that make it survive contact with real users are exactly the parts a fixed price punishes you for building.

Meanwhile the client's incentive is to push everything possible inside the boundary, because anything outside it costs extra. So you get a contract where one party is trying to expand scope and the other is trying to contract quality, and the product is what falls out of the gap.

We have been on the wrong side of that. It is the one engagement pattern where we have consistently ended up with a client who is unhappy and a team who did more work than they were paid for. Both of those are our fault for selling the shape, not the client's for buying it.

What we do instead

We sell a build one phase at a time. Each phase has a fixed price, a stated set of acceptance tests, and — this is the part that matters — a stated list of non-goals.

The non-goals are the useful half. 'This phase does not include the reporting module, the bulk import, or the second language' is worth more than any amount of detail about what is included, because it is the thing that actually gets argued about later. Writing it down before the money moves means the argument happens while it is still cheap.

At the end of a phase you have working software and a real number for what the next phase costs, produced by people who have now touched the code rather than estimated from a document. You can also stop. That is not a failure mode we are trying to design out; a client who stops after phase two with something that works has had a better outcome than one who spent the whole budget on a spec that was wrong in month one.

When a fixed price is fine

Fixed pricing is not always wrong. It works when the whole thing is genuinely known: a well-specified integration between two systems that both already exist, a migration where the data shape can be inspected in advance, a defined change to something we already run.

The test we apply is simple. Can we name what would make this take twice as long, and have we already checked whether it is true? If yes, a fixed price is honest. If the honest answer is 'we would find out once we start', then quoting a fixed price for the whole thing is selling certainty we do not have.

What this means if you are buying

If a supplier quotes a fixed price for a product that does not exist yet, ask two questions. What are the non-goals? And what specifically would make this estimate wrong?

A good answer names things. 'If your payment provider does not support partial captures we would need a different reconciliation approach, and we have not confirmed that yet.' A bad answer reassures you. The reassuring answer is the one that becomes a change order in month three.

We would rather lose the work at the quote than win it and spend six months arguing about a document.