On this page
Consider an illustrative comparison, not a client case study or a price quote. Two hypothetical founders hire two developers for similar projects. The first agrees a fixed price of $15,000, feels safe, and six months later is trapped in scope-change arguments with a developer who resents every request. The second agrees $70 an hour, feels nervous, and gets a smooth project that lands around the same total, because the developer had no reason to fight her about changes.
Then two other founders make the same two choices and the outcomes flip. The fixed price project sails through, and the hourly one bleeds money for a year with nothing shipped.
I have worked under both models for years, on both good and bad projects, and here is the truth nobody selling you either model will say: neither model protects you. The match between the model and the type of work is what protects you. This article shows you how to pick the right one for your situation, and how to spot the traps in each.
What each model actually trades
Every pricing model is an agreement about who carries which risk.
Fixed price means the developer carries the estimation risk. If the work takes longer than they guessed, they eat the difference. In exchange, they price that risk in: a sensible developer quotes a fixed price well above their expected cost, because some projects go sideways. You are paying a premium for certainty.
Hourly means you carry the estimation risk. If the work takes longer, you pay more. In exchange, you skip the risk premium and you buy flexibility: changing your mind mid-project is normal business, not a contract negotiation.
Neither is cheaper in general. Fixed price caps your downside but you pay the insurance; hourly is usually cheaper when the project goes well and more expensive when it does not. The real question is not "which is cheaper" but "which risks do you want to hold".
The variable that decides it: how well-defined is the work?
Here is the rule I give people, and it resolves almost every case.
Fixed price works when the work can be fully described in advance. Hourly works when it cannot. Everything else is detail.
A well-defined project looks like: "rebuild this existing five page site in a modern stack, same content, new design, these three integrations". The unknowns are small. A developer can scope it, price it, and a fixed price serves everyone: you get certainty, they get a clean target.
A poorly-defined project looks like: "we have an idea for a product, here is a rough sketch, we will learn what it needs as users react". This is most startups and most new products. The unknowns are the whole point. A fixed price here is a fiction, because the thing being priced does not exist yet, and one of two bad things follows. Either the developer padded the price enormously to cover the unknown, and you overpaid. Or they underpriced it, and midway through, the incentives turn poisonous: every request you make is now a cost to them, so the answer to everything becomes "that's out of scope". You wanted a partner; the contract made you opponents.
That incentive rot is the part first-time buyers underestimate. The most expensive thing in software is not an hourly rate. It is a developer who has stopped wanting your project to grow.
The failure modes of each, honestly
Where fixed price goes wrong. The scope document becomes the battlefield. Anything not written down is an argument. Change requests get priced at panic rates because the developer is protecting a shrinking margin. Quality drops at the end, because when time runs out on a fixed bid, testing and polish are what get cut, and you will not find out for months. And the bidding phase itself selects badly: the lowest fixed bid usually comes from whoever understood the project least.
Where hourly goes wrong. Without discipline, there is no forcing function. Weeks pass, invoices arrive, and "almost done" floats forever. You cannot tell whether slow progress is honest difficulty or a comfortable meter left running. The fear people have of hourly is real, it is just aimed at the wrong thing: neither billing model replaces visible progress, clear responsibilities and evidence that the work meets the agreed requirements.
Both failure lists have the same cure, and it is not a contract clause. It is short cycles and visible output. Weekly demos of working software, a shared list of what is next, and small increments you approve as you go. A developer who works this way is safe under either model. One who does not is dangerous under both.
The model most people overlook: milestones
For most real projects, the best answer is not pure fixed or pure hourly but the hybrid: milestone pricing. Break the project into chunks of one to three weeks, each with a defined deliverable and a fixed price for that chunk alone. "User accounts and login, working, $2,500. Then we scope the next chunk."
Why this works so well:
- Each chunk is small enough to estimate honestly, so nobody is pricing fog.
- You get fixed-price certainty at a scale where it is real, and hourly-style flexibility between chunks, because after any milestone you can change direction, pause, or walk away with working software.
- Trust builds on evidence. After two milestones delivered on target, you stop worrying, and you have real data on pace and quality before committing serious money.
- It is the cleanest way to start with a stranger. The first milestone is effectively a paid audition for both sides, the same logic as the paid trial I recommend in my guide to hiring a full stack developer.
For ongoing work after launch, fixes, improvements, small features, the natural model is a retainer: a fixed monthly amount for an agreed capacity. Predictable for you, stable for them, and no per-task negotiation.
The comparison in one table
| Situation | Best model | Why |
|---|---|---|
| Small, precisely defined job (audit, migration, landing page) | Fixed price | Unknowns are small, certainty is cheap |
| New product, evolving scope | Milestones (or hourly with weekly demos) | Fixed price on fog breeds conflict |
| Working with someone new | First milestone as paid trial | Evidence before commitment |
| Ongoing improvements after launch | Monthly retainer | Predictable both ways |
| Emergency rescue, unclear codebase | Hourly, capped per week | Nobody can honestly fix-bid a mystery |
| You mainly need cost certainty for a board or budget | Fixed price, generous written scope | Buy the insurance, accept the premium |
Rates, and why cheap hours are expensive
Whatever the model, you will compare rates, so a word on reading them.
For illustration only, assume one proposal needs twenty hours at $80 and another needs ninety at $30: the totals are $1,600 and $2,700. These assumed figures are not market rates, observed client results or evidence that seniority guarantees faster delivery. Compare estimates for the same scope, including testing, rework, handover and ongoing support. Ask for relevant work and the assumptions behind the estimate, not just an hourly rate.
The same logic applies to suspiciously low fixed bids. A fixed price only protects you if the person can survive delivering at that price. A bid at half of everyone else's is not a bargain, it is an unfunded promise, and it resolves later as abandonment, quality collapse, or a renegotiation with you over a half-built product. The cheapest bid and the most expensive project are frequently the same document.
What I do, for transparency
Since this whole article is advice from one side of the table, here is my own practice, so you can judge the advice against the incentives. I quote small defined jobs at a fixed price. I quote products as milestones, first milestone deliberately small. I take rescue work hourly with a weekly cap until the codebase stops surprising us, then switch to milestones. Everything runs on weekly demos regardless of model. Clients who came from a bad fixed-price experience relax somewhere around the second demo, when they realize they can see the software growing instead of reading progress reports about it.
If you have a project and are unsure how it should be priced, describe it to me and I will tell you which model I would put it under and roughly what the first milestone would look like. That costs you nothing and gives you a template to hold against any developer you talk to, including me.
Quick answers
Which is cheaper, fixed price or hourly? Neither, systematically. Fixed price includes a risk premium; hourly transfers the risk to you. Match the model to how well-defined the work is, and manage with weekly demos. That is what controls cost.
How do I stop hourly billing from running away? Weekly caps, weekly demos of working software, and small approved increments. You should never be more than one week of budget away from your last look at real progress.
Is it rude to ask for a paid trial or small first milestone? No, it is standard professional practice, and good developers often prefer it, because auditioning a client works both ways. Be wary of anyone who demands a large commitment before any working output.
What belongs in a fixed price contract? The scope in concrete detail, what is explicitly out, the change process with rates, milestones and payment schedule, ownership of code and accounts (yours), and what "done" means, ideally as a checklist you both sign.
My developer quoted one big fixed price for my whole startup idea. Red flag? Usually, yes. Either it is heavily padded or it will end in scope warfare. Ask them to break it into milestones with the first one small. How they respond to that request tells you most of what you need to know.
