Hourly or Fixed Price? Paying a Web Developer

Fixed price when the scope can be written down before work starts — it protects your budget and moves the estimating risk to the developer. Hourly when the work is genuinely exploratory, ongoing, or likely to change direction — it protects your flexibility and stops you paying a padding premium for uncertainty. Retainer when the work never really ends. Neither of the first two is more honest than the other; they allocate the same risk to different people.

That last point is the one that gets lost. Every project carries the risk that it takes longer than anyone thought. Fixed price puts that risk on the developer, and they price it in. Hourly puts it on you, and you pay it only if it materialises.

Not sure which fits your project? Describe what you're trying to build and I'll tell you which model I'd use and why — including when I'd say hourly, which isn't how I usually work. Get in touch.

Fixed price

What it protects

Your budget, absolutely. You know the number before you commit, you can get board or partner approval against it, and an overrun is the developer's problem rather than yours. For a business that needs to plan cash flow, this is worth a great deal.

It also forces a useful conversation. A developer can't quote a fixed price without understanding the project, so the estimating work happens before you commit money instead of being discovered afterwards.

What it costs you

Two things, and both are real:

• A risk premium. The developer is carrying the overrun risk, so the price includes a buffer for it. On a well-understood project that buffer is small. On a vague one it's large, because it has to be.
• Change friction. Once the scope is fixed, every new idea is a variation with a price attached. That's the mechanism working as designed, but it can feel adversarial mid-project — especially when the new idea is obviously good.

When it goes wrong

When the scope wasn't actually settled. A fixed price on an unclear brief is the worst of both worlds: you pay the uncertainty premium *and* you still end up in change-request conversations. Fixed price only works with a written scope — which is why what should be in a web development quote matters more here than anywhere else.

Hourly

What it protects

Your flexibility, and your money on well-run projects. You can change direction without renegotiating, you only pay for work actually done, and you're not funding someone else's risk buffer. On genuinely exploratory work — where the right answer emerges as you go — it's the more honest model.

What it costs you

Certainty. You don't know the final number, and neither does anyone else. That's fine with a developer you trust and uncomfortable with one you don't — and it's why hourly tends to suit second projects rather than first ones.

It also puts a quiet tax on your own decisiveness. Every time you change your mind, the meter runs. Some clients manage this well; others find it makes them hesitant in ways that hurt the project.

When it goes wrong

When there's no cap, no estimate and no reporting. Hourly without an agreed ceiling is an open-ended commitment, and "it'll take as long as it takes" isn't a plan. Ask for an estimate in hours, a not-to-exceed figure, and a regular report of hours used against that estimate. A developer who won't give you those three is asking for a lot of trust.

Retainer

For work that doesn't have an end — maintenance, ongoing improvements, someone on call when something breaks. You buy a block of hours or an agreed scope of coverage each month.

Published NZ figures: $50–$200/month for website maintenance and $1,500–$5,000/month for support on a mid-complexity application. In Cyprus, €100–€500/month for maintenance, or €500–€2,000/month for an ongoing freelance engagement.

The thing to check in a retainer is what happens to unused hours, and what counts as covered. "Maintenance" that means monitoring is a different product from "maintenance" that means someone actually does work. Detail in annual website maintenance costs.

Which one for which project

What I use, and the downside

I work fixed-scope, fixed-price. The reasoning is that most of my clients are small businesses making a considered purchase, and for them budget certainty is worth more than flexibility — they'd rather know the number than optimise it.

The honest downside: it means more work before we start. I can't give a fixed price without understanding the project properly, so there's a scoping conversation you have to invest in before you get a number. And it makes me a poor fit for genuinely exploratory work, where the requirements are meant to emerge — in that situation an hourly developer will serve you better, and I'd tell you so rather than pad a number to cover the unknown.

For inherited codebases I'd also start hourly or with a small paid audit, for the reason set out in taking over a website from another developer: nobody can honestly fix-price the work of understanding someone else's decisions before reading them.

Frequently asked questions

Should I pay a web developer hourly or a fixed price?

Fixed price when the scope can be written down before work starts, which covers most marketing sites and defined builds — it gives you budget certainty and puts overrun risk on the developer. Hourly when the work is exploratory, ongoing, or lands in an existing codebase nobody has read yet, because a fixed price on an unknown gets padded and you pay for the padding whether or not the risk materialises.

Is fixed-price web development more expensive?

On a well-defined project, only slightly — the risk premium is small when the risk is small. On a vague brief it's substantially more expensive, because the developer has to price the uncertainty. That's an argument for settling the scope before asking for a fixed price, not an argument against fixed price.

What are the risks of hourly web development billing?

Open-ended cost, mainly. Protect yourself with three things in writing: an estimate in hours, a not-to-exceed cap, and a regular report of hours used against the estimate. Hourly billing with none of those is an unlimited commitment, and it's the arrangement most likely to end in a dispute about value rather than about work.

Can I switch from hourly to fixed price mid-project?

Often yes, and it's a sensible pattern: hourly for discovery until the requirements are clear, then fixed price for the build once they are. Many application projects are structured this way deliberately, with a paid discovery phase priced at $5,000–$15,000 in NZ before a fixed build quote is given.

What is a web development retainer?

A monthly agreement covering ongoing work — maintenance, updates, small changes and availability when something breaks. NZ published ranges are $50–$200/month for a website and $1,500–$5,000/month for a mid-complexity application; Cyprus runs €100–€500/month. Check what counts as covered, since monitoring-only and work-included retainers are very different products at similar prices.

Where to start

Ask yourself one question: can I describe what I want in enough detail that two developers would build roughly the same thing? If yes, get a fixed price. If no, either do the work to get there, or accept hourly and put a cap on it.

If you're unsure which side of that line you're on, describe the project and I'll tell you honestly. Get in touch, or see what I build.