Fixed price or hourly is not a taste question. It is a bet about who is wrong about the scope, and who pays for being wrong.
Pick fixed price when you can write the MVP's scope on one page — features, user types, and a date. Pick hourly, or capped hourly, when the work is exploratory or fixes someone else's codebase: the honest price for uncertain work is the actual hours, not a guess with a risk premium baked in.
That's the whole decision. The rest is what each model actually costs you.
What's the real difference between fixed price and hourly?
Fixed price is a single number for a defined scope. You know the ceiling before a line of code ships, and the developer or studio absorbs the risk if the estimate was wrong. Hourly is the mirror image: you pay for actual time worked, so every meeting, every "can we also add," and every bug hunt shows up on the invoice, and you absorb the risk of the estimate being wrong.
Capped hourly — sometimes called time-and-materials with a ceiling — splits the difference. You pay hourly up to an agreed cap, and anything past the cap needs a written change order before work continues. It behaves like fixed price on the downside and like hourly on the upside.
Why do agencies pad fixed-price quotes by 20-40%?
Because they are pricing a bet, not a task list. Every fixed-price quote has to cover the scenarios the scope document didn't anticipate: a third-party API that turns out to be poorly documented, a "simple" login flow that needs SSO after all, a founder who reviews once a week instead of once a day. Industry estimates put that risk premium at roughly 20-40% above the honest hourly cost of the work, and the number climbs with how vague the spec is.
That premium is not dishonest. It's the price of certainty. The dishonest version is the studio that quotes without the premium, wins the bid, and recoups the difference through change orders once the contract is signed.
Fixed price vs hourly vs capped hourly, side by side
| Fixed price | Hourly (T&M) | Capped hourly | |
|---|---|---|---|
| Scope certainty needed | High — the build fits on one page | Low — fine to build as you learn | Medium — a real spec, but room for surprises |
| Who eats change-order risk | The builder, until scope changes — then you, via a change order | You, continuously | Shared — the builder up to the cap, you past it |
| Typical markup / premium | 20-40% above honest hourly cost, industry-typical | None — you pay for actual time | A smaller buffer built into the cap |
| Best-fit scenario | A defined MVP v1 with a written scope document | Exploration, R&D, or fixing an inherited codebase | A scoped first MVP where you want a ceiling, not a black box |
What happens when scope changes mid-fixed-price project?
It always does, a little. The fix is not a better estimate — it's a change clause written into the contract before anyone starts. We wrote about the one-page contract and the out-of-scope list that makes this workable in Contracts before code: three lines of in-scope, three of out-of-scope, and one paragraph on what happens when the scope moves. Without that paragraph, "just one more thing" becomes free labor for the builder or a surprise invoice for the founder, and neither side leaves trusting the other.
Is capped hourly safer for a first-time founder?
Usually, yes, if you can't yet describe your v1 tightly enough for a true fixed-price bid. Capped hourly gives you the one thing founders actually want from fixed price — a number you can't blow past without agreeing to it first — without paying the full risk premium for certainty you don't need yet. The tradeoff is more of your own attention: someone has to watch the clock and sign off on a cap increase, because nobody else will do it for you.
What does SingleBit default to?
We quote fixed price for a scoped MVP: a price and a date, in writing, before a repo is cloned, because founders come to us wanting a number they can plan a runway around, not an open tab. When the scope is genuinely undefined — an R&D spike, a proof-of-concept, "help us figure out if this is even possible" — we say so and price it hourly instead of forcing a fixed number onto an open question. The model should match the certainty, not a preference for one over the other.
Heuristics
- Fixed price when you can write the scope on one page. If you can't, the number you get is a guess, not a quote.
- Hourly when the work is genuinely exploratory. Paying for real hours beats paying a stranger's risk premium on invented certainty.
- Capped hourly is the sane middle for most first MVPs. A ceiling without the full fixed-price markup, at the cost of a little more of your own attention.
- The billing model doesn't replace the change clause. Pick the model, then write the paragraph that says what happens when scope moves.
The contract, not the pricing model, is what keeps a build honest once it starts.
Written 2026-07-25 by Naman Barkiya.