If you're hiring a web developer, you'll be asked, or told, how the project will be priced. Fixed price, hourly, or milestone-based. It sounds like a billing detail, but it decides who pays when the work takes longer than planned. And it almost always takes a little longer than planned.
Short answer: fixed price fits clearly defined work, hourly fits uncertain or ongoing work, and milestone-based fits larger projects where some details get discovered along the way. What matters most is who carries the risk when things change.
I've written before about scoping a project before any code gets written, and fixed price works best once the scope is clear. This post covers the rest: what to do when it isn't, and how to avoid getting surprised either way.
The real question is who carries the risk
Every pricing model answers one question: when the work turns out bigger or slower than expected, who pays for it?
With a fixed price, the developer carries that risk. With hourly, you carry it. With milestones, the risk is split into smaller pieces, so neither side is stuck with one big surprise.
Fixed price
You agree on a total price for a defined piece of work. The developer delivers it, you pay.
This works well when the scope is known. A brochure website with a handful of pages, where the content is ready and the design is agreed, is a good example. Both sides know what "done" looks like.
It goes wrong when the scope is still being figured out. Here's a made-up example. Imagine a founder asks for "a booking system" at a fixed price. Halfway through, they realize customers need to pay a deposit and get reminder emails. The developer says that's extra, because it wasn't in the quote. The founder feels nickel-and-dimed. The developer feels like the goalposts moved. Nobody is being dishonest. The scope was never really defined.
Keep in mind that a developer who takes on the risk may price some of it in. A fixed quote that looks very low is worth a question about what's left out.
Ask:
- What exactly is included, and what is explicitly not included?
- What counts as a change, and how is a change priced?
- How many rounds of revisions are included?
Hourly
You pay for the time spent. The final cost isn't known upfront, but you only pay for work that actually happens.
This fits work that can't be defined well in advance: ongoing improvements to an existing site, a list of small fixes, investigating a problem, or early exploration while you're still deciding what to build.
It goes wrong when there are no limits and no visibility. Unclear work tends to expand, and if nobody is watching the hours, the project drifts.
Ask:
- Will I get a regular summary of hours and what they went toward?
- Is there a cap, or a point where we stop and check in?
- What counts as billable? Meetings? Research? Waiting on my feedback?
Milestone-based
The project is split into stages. Each stage has its own price and its own delivery, and you pay as each one is finished.
For anything bigger than a few weeks, this is often a good fit. You see real progress early, you can change direction between stages, and if the relationship isn't working, if the contract allows it. It's especially relevant for an MVP, and you can read more on my MVP development page.
It goes wrong when the milestones are vague. "Phase 1: backend" tells you nothing. A good milestone is something you can open and use. "Visitors can sign up and see their dashboard" is a milestone. "Set up the database" is a task.
Ask:
- What does "done" mean for each milestone, in plain words?
- What happens to the schedule and payment if one milestone runs late?
- Do I own the work completed so far if we stop midway?
How to choose
- Clear scope, unlikely to change: fixed price.
- Unclear scope, or ongoing work: hourly, with a cap or regular check-ins.
- Larger project with details still to discover: milestone-based.
You can also mix them. A small fixed-price first stage to define the scope properly, followed by milestones or hourly work for the rest, can save more money than a rate negotiation. I work with all three models myself, and the right one depends on the project.
What matters more than the model
A pricing model is only as good as the agreement around it. A fixed price with a vague scope is worse than hourly with a weekly check-in. A milestone plan with unclear milestones is just a fixed price in disguise. Whatever the model, I'd want these in writing:
- what is included and what isn't,
- who owns the code, the domain, and the hosting accounts when the work is done,
- how changes are handled,
- and what happens after launch, including who fixes problems and how that's priced.
If you're still comparing developers, my posts on hiring a web developer without getting burned and what a small business website costs cover the questions around this one.
Common questions
Is fixed price always cheaper than hourly? No. Fixed price gives you certainty, not savings. The developer may include a buffer for the unknowns, and hourly can cost less when the work is small or finishes quickly.
Can I switch models partway through? Often yes, for example from a fixed-price scoping stage to milestones. Agree on how the switch works in writing before it happens.
Should I pay upfront? A deposit is common. For larger amounts, it's reasonable to tie payments to delivered work you can actually see.
Which pricing model is best for a small business website? Clear pages, content and design mean fixed price. Unclear or ongoing work means hourly with a cap.
None of this is a rule. It's how I'd think about it if I were the one hiring: match the pricing model to how well you understand your own project, and know where the risk sits before it shows up.
If you're planning a small business website and want to talk through the scope and how it should be priced first, you can see how I approach these projects on my small business website service page.