introI like fixed-price work. Most founders do. It is easier to budget, easier to commit to, and easier to compare against the endless blur of hourly estimates. But fixed-price only works after version one gets cut down hard. If the MVP is still a pile of maybes, the price is fiction. What does work is a smaller build with written boundaries, visible exclusions, and one person on each side who can make decisions fast.
article sectionsFixed-Price Works Best When the First Release Is Narrow
I am comfortable quoting fixed-price when version one is narrow enough to describe without waving my hands around. One workflow. One launch path. One person who can say yes or no when tradeoffs show up. That is usually enough. If the project still needs deep discovery, several stakeholder rounds, or a backlog full of unknown integrations, the number will either be fake or padded so hard it stops being useful. A small MVP is different. You can name what gets built, what stays out, and what counts as done before the build starts.
- /One launchable workflow instead of a broad roadmap
- /A short list of integrations and not many unknowns
- /One decision-maker who can cut scope without a committee call
What Must Be Defined Up Front
Before I start, I want one written picture of the first release that both sides can point to. Scope. Deliverables. Exclusions. How feedback works. How approval works. This is the part many founders want to skip because it feels slower than jumping into build mode. In practice, this is what keeps the build moving. If a feature matters, it needs to be named. If it is not named, it is either out of scope or it belongs in a later phase. Fixed-price only works when the boundaries are visible.
- /What is included in version one
- /What is out for this phase, even if it may matter later
- /How delivery, feedback, and sign-off will work
Fixed Price Is Not Scope Amnesia
New ideas always show up once the build is moving. That part is normal. The problem starts when those ideas get treated like tiny favors instead of scope changes. If something new appears, there are only a few honest options: swap it for something already in scope, move it to phase two, or reprice the work. What breaks projects is pretending the original number still means the same thing after the scope changed underneath it.
- /Keep new requests visible instead of sneaking them into the build
- /Trade scope for scope when the new ask matters more than the old one
- /Create a second phase only when the project genuinely got bigger
Sometimes Hourly Is the More Honest Model
Sometimes hourly is just cleaner. If we are still figuring out what the product is, or if the workflow depends on third-party systems nobody has tested yet, fixed-price turns into theater. I would rather say that the project is still exploratory than wrap that uncertainty in a fixed bid and hope nobody notices. Once the unknowns are gone, it is much easier to price the next phase properly.
- /Use hourly when discovery is still part of the job
- /Use fixed-price when version one is already small enough to define
- /Move back to fixed-price after the unknowns are gone