Every time a founder asks me “fixed-price or hourly?” I have to resist the urge to answer with a different question. The honest answer is that the pricing model is downstream of how well either of you understands the scope, and most MVP scopes are understood much worse than the founder thinks. So you end up choosing between two ways of being wrong: a fixed price that’s wrong about the work, or an hourly rate that’s wrong about the budget.
This post is the rubric I actually use when a SaaS MVP lands in my inbox. It walks through the small amount of arithmetic that makes the choice obvious in most cases, the failure modes on each side, and a worked example of how the same project shakes out under both models. It is not a “fixed-price is always better” post, because it isn’t, and it isn’t the opposite either.
What we’re actually comparing
Fixed-price means: you and the contractor agree a scope and a number. The number does not change unless the scope changes. The risk of “this took longer than expected” sits with the contractor.
Hourly (or daily) means: you pay for time, against a loose cap if you’re lucky. The risk of “this took longer than expected” sits with you, the buyer. Most “time and materials” arrangements in practice are weekly invoices with a soft ceiling that nobody enforces until they do.
There is a third shape — “milestone-based with a not-to-exceed cap” — that is really fixed-price wearing an hourly hat, and I’ll treat it as fixed-price for this post.
The thing to be precise about: these are not pricing models. They are risk allocation models. Fixed-price prices the deliverable. Hourly prices the contractor’s attention. You’re not picking how to pay; you’re picking who eats the variance.
The core rubric: variance, not rate
The first mistake almost every founder makes is comparing the hourly rate to the fixed-price total divided by an estimated hour count. That number is misleading because it does not include the variance.
Here is the rubric I run in my head, in plain language.
- Scope clarity. Can you, today, write a one-page description of what “done” looks like? If yes, fixed-price gets easier. If no, hourly is honest.
- Discovery weight. What fraction of the work is “figure out what we’re building” versus “build a thing we’ve agreed on”? Heavy discovery → hourly. Heavy execution → fixed.
- Change appetite. How often do you expect to change your mind in the first 30 days? Founders almost always under-report this number. Honest answer high → hourly with discipline, or short fixed-price slices.
- Your downside tolerance. What happens to the company if the project costs 2× the estimate? If the answer is “we miss payroll,” you cannot afford uncapped hourly, full stop.
- Their downside tolerance. Is the contractor a solo operator who would feel a 50% overrun, or an agency that prices the variance in? Solo + fixed-price + tight scope can be a great deal for both sides. Solo + fixed-price + vague scope is how good engineers learn to hate clients.
A rough decision table that lines up with how I actually quote:
| Situation | Default model | Reason |
|---|---|---|
| One-page spec, known stack, 4-8 week MVP | Fixed-price | Variance is bounded; both sides win on predictability |
| ”Help me figure out what to build” | Hourly, discovery phase only | You’re paying for thinking, not deliverables |
| Long-running improvements after launch | Hourly cap or retainer | Stream of small asks, no clean deliverable |
| Integration with messy legacy system | Hourly with milestone gates | Unknown unknowns are real and uncoverable until you’re inside |
| ”We need this for a demo in 3 weeks” | Fixed-price, narrow scope | Time pressure rewards a hard scope freeze |
Notice that none of these rows say “$X/hr is too expensive.” Rate is a distraction. A senior contractor at a high hourly rate who finishes in a third of the time of a junior is cheaper in absolute dollars and ships sooner. The variable that matters is the expected total cost with variance, not the headline number.
Where each model goes wrong
The fixed-price failure mode is the change request war. You agreed a scope. Three weeks in, you realise the login flow needs SSO because your first interested customer is enterprise. The contractor, who priced the work without SSO, now has to either eat the additional days or write a change order. Either path corrodes the relationship. Repeated change orders are a signal that the original scope was a guess dressed up as a spec.
The hourly failure mode is the drift to infinity. There’s no forcing function on “is this still worth building?” Every Friday’s invoice feels reasonable in isolation. Eight Fridays later you’ve spent twice what you would have on a fixed-price MVP and you’re still in pre-launch. Hourly without a cap, without a weekly burn-down, without a “what does done look like?” conversation, is a category of bug.
There’s a third failure that belongs to neither model: the wrong contractor for the shape of the work. An agency built around a six-month engagement cycle does not know how to ship a four-week MVP, and a solo engineer who’s never priced a fixed bid will under-quote and resent you. Match the shape of the contractor to the shape of the work before you argue about price.
A worked example, conceptually
Suppose the scope is a Rails SaaS MVP: marketing site, auth, Stripe-billed accounts, a single core workflow, basic admin, deploy to a managed host. The kind of thing I write about in scoping a Rails MVP for 4–8 weeks.
Under fixed-price, the contractor sizes it at roughly six weeks of focused work and quotes a single number that bakes in a buffer — typically 20–30% above the median estimate, because they’re the one eating variance. The contract names the deliverables explicitly and lists what is not included. Changes cost money and the price list is in the contract. The founder gets predictability: same number on the invoice in week one and week six.
Under hourly, the same contractor quotes a rate and an estimated range — say, “expect somewhere in the region of X to Y hours.” There’s a weekly check-in, a written burn-down, and a soft cap that triggers a conversation rather than a stop. The founder pays less if the work goes well, more if it doesn’t, and is on the hook for change-of-mind moments along the way.
The interesting observation, in my experience: the expected total cost between these two scenarios usually lands within 10–15% of each other. The fixed-price has a buffer baked in; the hourly has variance that, averaged across projects, eats most of the buffer the other way. What differs is the distribution of outcomes. Fixed-price collapses the distribution onto a single number. Hourly preserves the spread and hands it to the buyer.
If you’re a founder with one shot of runway, you don’t want a wide distribution. You want a single number you can write down on your cash-flow spreadsheet. That preference alone is often enough to pick fixed-price even when the math looks like a tie.
The pricing model is a forecast of how good both of you are at saying no to scope creep. Pick the model that matches how disciplined you actually are, not how disciplined you wish you were.
What “done” looks like under each
A fixed-price engagement is done when the deliverables on the SOW are demonstrated working in production. Not “feature-complete on a branch.” Not “ready for QA.” The contract should say “deployed, accessible at this URL, with these acceptance criteria observably true.” Anything less and the last 10% becomes a sliding goalpost.
An hourly engagement is done when one of three things happens: the work specified for that phase is shipped, the agreed cap is hit, or the founder calls it. The hardest part of hourly is exercising the third option. The contractor will not, in good conscience, tell you to stop paying them. That’s your job. Set a calendar reminder for the cap and treat it as a checkpoint, not a soft suggestion.
In both cases, “done” should include the boring things: deploy pipeline runs cleanly, secrets aren’t in the repo, error tracking is wired up, the founder can log in and see their own data. I’ve written about hiring a Rails contractor when you can’t code yourself; the acceptance checklist there applies regardless of pricing model.
When neither rubric applies
Two situations break this whole framework.
The first is when the project is genuinely research-shaped — “I want to know if RAG over our knowledge base produces useful answers.” There’s no fixable scope because the deliverable is knowledge, not software. Pay hourly, set a budget cap as a learning fee, and accept that the output might be “no, this approach doesn’t work” and that’s still valuable.
The second is when you don’t actually need an MVP — you need a prototype to show an investor or a single design partner. That’s a different beast: smaller, throwaway, optimised for one conversation rather than for real users. Fixed-price still works, but the scope should be ruthlessly short and the contract should explicitly say “this is not production code.”
A small claim to land on
If you compute the variance honestly, fixed-price and hourly almost never differ by more than 15% in expected total cost on a well-scoped 4–8 week MVP. The case for fixed-price isn’t that it’s cheaper. It’s that it forces the painful scope conversation before money starts flowing, and that conversation is the part of the project most founders skip and most regret skipping.