Hourly vs fixed-price vs milestone: choosing your engagement model
None of these three models is universally "better" — each one has a specific failure mode when it's used for the wrong kind of work. Picking the right one for your situation prevents most billing disputes before they happen.
Hourly
Best for: open-ended support, bug fixes, ongoing maintenance, or work where scope is genuinely unclear at the start.
Failure mode: feels risky to clients who worry about unbounded cost. Fix: ask for logged hours with a short daily or weekly note, and set a rough budget ceiling to check in against.
Fixed-price
Best for: small, clearly defined deliverables — a landing page, a specific feature, a well-scoped integration.
Failure mode: scope creep. If requirements shift mid-project, either the developer eats the cost (breeds resentment, rushed work) or the client gets nickel-and-dimed with change requests. Fix: lock scope in writing before work starts, and treat any addition as a new, separately-priced item.
Milestone
Best for: medium-to-large builds — an MVP, a multi-feature product — where you want fixed-price predictability but with checkpoints instead of one all-or-nothing delivery.
Failure mode: vague milestones ("phase 1 complete") that are hard to verify objectively. Fix: define each milestone as a specific, demoable deliverable — "user auth + dashboard, working and deployed to staging" — not a vague phase label.
A simple way to decide
- Do you know exactly what you want built? If yes and it's small — fixed-price. If yes and it's substantial — milestone.
- Is the scope genuinely unclear or evolving? Hourly, with a budget check-in cadence.
- Is this ongoing support with no defined end? Hourly is really the only model that fits.
Whichever model you pick, the actual protection against disputes isn't the billing model itself — it's writing down what "done" looks like before work starts. Vague scope breaks every model equally.
Mixing models
It's common — and often smart — to mix models across a single engagement. A milestone-based MVP build followed by hourly maintenance once it's live is a normal, healthy pattern. Don't feel locked into one model for the entire relationship.
Not sure which model fits your project?
We'll recommend one honestly based on your actual scope, on a free scoping call.
Discuss on WhatsApp