Fixed price is fair when the scope is clear; hourly is fair when the work is genuinely open-ended. For most web projects with a defined outcome — a site, an MVP, a portal — fixed price against a written scope protects you, because you know the number up front and the risk of estimate misses sits with me, not you. Hourly fits discovery, ongoing changes, or work nobody can scope yet. Match the model to the certainty.
When is fixed price the right model?
When the outcome is defined enough to scope: a known set of pages, features, or a clear v1. Fixed price means you approve a number before work starts and pay that number, regardless of how long it takes me. The risk of a bad estimate is mine to carry, which is exactly why I scope carefully first. For most client builds this is the fair default — it gives you budget certainty and aligns us on shipping the agreed thing. It also changes how decisions get made: because the price is set, there's no incentive to drag the work out, and every conversation is about shipping the agreed outcome rather than logging hours. You're buying a result, not time.
When does hourly make more sense?
When the work is genuinely open-ended: early discovery, ongoing iteration after launch, or a scope that will obviously change week to week. Hourly is honest there, because pretending to fix a price on unknown work just means padding the number. The catch is you carry the risk — costs rise if the work grows. I use hourly for maintenance and continued iteration, where flexibility matters more than a fixed total and the scope is meant to move. The honest version of hourly comes with visibility: regular updates on where the hours went and what's next, so "flexible" never quietly becomes "unbounded." You should always be able to see what you're paying for.
What's the hidden risk in each?
In fixed price, the risk is vague scope: if the brief is loose, either the quote is padded or change requests pile up as extras. In hourly, the risk is an open meter with no ceiling. I manage both the same way — a clear written scope up front, and a cap or checkpoint on hourly work so it never runs away quietly. The model isn't the problem; an unclear agreement is. Get the scope right and either can be fair. The thing to watch in any contract is how changes are handled: a fixed-price build needs a simple, written change process, so a mid-project addition is a clear conversation about scope and cost, not a silent overrun or an awkward fight. Agree how change works before you need it.
What about a fixed scope with a hybrid model?
Most healthy engagements are actually both, in sequence. You fix the price for the defined build — the part with a clear outcome — then move to hourly (or a small monthly retainer) for the open-ended work that comes after launch: iteration, new features, maintenance. That way the risky, scoped part has budget certainty, and the genuinely open-ended part has flexibility, each priced the way that's fair for it. The mistake is forcing one model across both phases — fixing a price on unknown future work means padding, and metering a clearly scoped build means you carry estimate risk you shouldn't. Use fixed for the known, hourly for the unknown, and say which is which up front.
Which is cheaper for the client?
Usually fixed price, for defined work — and not because the rate is lower. With fixed price you carry no estimate risk: if the build takes longer than expected, that's on me, not your invoice. Hourly can look cheaper per hour and still cost more overall, because every change, every slow decision, and every underestimate lands on your bill. Fixed price also forces the scoping conversation up front, which is where most waste gets cut. Hourly only wins on cost when the work is genuinely small, or so open-ended that a fair fixed quote would have to be padded to cover the unknowns — at which point you're paying for certainty you don't need yet.
How do I price a build?
I scope the outcome first, then quote most defined builds fixed-price so you know the number before work begins — that's how my services are structured. Open-ended or post-launch work goes hourly with a clear cap. Either way you see the scope and the price in writing before any work begins, because surprise invoices are how trust dies. Certainty up front is part of the deliverable, not an extra.
Related strategy guides
See how to budget a software project, how to write a project brief, and freelancer vs agency vs studio.
Want a clear number for your project? Tell me what you're building — I'll scope it and quote it straight.
