Clients like fixed prices because they know what they will spend. Studios dread them because the scope moves. After 60 projects we settled on a process that works for both sides.
Week one: the problem
We interview the people who will use the product, not only the people paying for it. The output is a one-page problem statement both sides sign.
Week two: the smallest useful thing
We map every feature and mark what must exist for the first release to be worth using. The price covers that list. Everything else goes into a backlog with its own estimate.
Since adopting this, 9 out of 10 projects have shipped within 10% of the original quote.
Why two weeks, not zero
Skipping discovery doesn't remove the work, it just moves it later, where it costs more. A requirement discovered in week six of a build means re-estimating, re-negotiating, and usually an unhappy conversation about who pays for the difference. Two weeks upfront is cheaper than any of that, and it happens before either side has committed real money to the wrong scope.
What goes wrong without this
The failure modes are consistent across projects: the people paying describe the feature differently than the people who will actually use it, "small" requests get agreed to verbally and never priced, and there's no shared definition of what "done" means for release one. A signed one-page problem statement and a priced must-have list close all three gaps before a single line of code is written.
How we price the backlog
Anything that doesn't make the must-have list for release one doesn't get dropped — it goes into a backlog with its own estimate attached. That means adding it back later is a small, specific decision ("yes, add the $X item"), not a renegotiation of the whole contract.