Most software gets bought by the hour, one way or another. Even when the invoice says “project,” the estimate underneath it is somebody’s guess at hours multiplied by a rate — and when the guess is wrong, which it usually is, the person holding the risk is whoever’s paying. That’s the quiet default of most development relationships: the client absorbs the estimate risk, and the vendor gets paid regardless of whether the thing shipped on time, on budget, or working.
What “fixed price” actually has to mean
Fixed price only means something if the price is fixed against a specific, scoped outcome — not a rough idea of features. “Build us a customer portal” isn’t fixed-price-able, because nobody can estimate it; it’s not specific enough to estimate against. “Build a portal where customers can view order status, download three document types, and submit support tickets that route to our existing helpdesk” can be fixed, because it’s specific enough that both sides can agree, in advance, on what “done” looks like.
That specificity is the actual product being sold in a fixed-price engagement — more than the code itself. It’s the discipline of scoping tightly enough that the estimate can hold, and it’s the willingness to say no to scope that would break that estimate, rather than quietly absorbing it into “additional hours.”
Why this shifts the risk — and the incentives — to the builder
Under an hourly model, a slow estimate or a scope that balloons mid-project mostly costs the client money and costs the vendor nothing — more hours means more revenue. Under a real fixed-price model, the same overrun costs the vendor margin. That single change in who absorbs the risk changes almost everything else about how the engagement gets run: scoping gets tighter up front, because loose scope is now the vendor’s problem. Estimates get more conservative and more honest, because padding an estimate to cover uncertainty comes out of the vendor’s own margin, not the client’s budget. And “scope creep” conversations happen early and explicitly, instead of showing up quietly on next month’s invoice.
None of this makes the software cheaper to build in some abstract sense. It makes the risk of a bad estimate sit with the party who’s actually in control of the estimate — which is the builder, not the buyer.
How to tell if you’re actually buying fixed price, or just being told you are
A few questions separate a real fixed-price engagement from an hourly one wearing a fixed-price label. Is the scope specific enough that a third party could read it and know what “done” means — or is it a paragraph of feature wishes? What happens, contractually, if the build takes twice as long as estimated — does the vendor absorb it, or does a change order appear? Is there a mechanism for the client to add scope mid-project, and does adding scope also mean extending the price, transparently, before the work happens rather than after?
If the answers are vague, the “fixed price” is really an hourly estimate with a single number attached to it — and the estimate risk hasn’t actually moved anywhere.
The upstream question that determines whether this even applies
Fixed-price only works when you actually know what you’re building — which is a smaller set of situations than most founders assume. If the real question is still “should we build this at all, or is there a cheaper fix upstream,” fixed-price is the wrong conversation to be having yet. We scope against a business outcome first, specifically so we don’t fixed-price the wrong build. More on how that scoping works on Technology, and on why we insist on that diagnosis before any build gets priced, on How We Work.
Tired of open-ended dev quotes?
Bring us the build. We’ll tell you what it should cost — fixed — or whether you need it at all.