Why I charge fixed prices instead of hourly rates

When I started freelancing, I charged by the hour. It seemed like the obvious model — you pay for my time, I deliver work. Simple.

It took about six months to realise it was wrong for everyone involved.

The problem with hourly billing

Hourly pricing creates a hidden conflict of interest.

The client wants the work done as fast as possible. The developer gets paid more the longer it takes. These incentives point in opposite directions.

I'm not saying most developers deliberately slow down — they don't. But the model structurally penalises efficiency. If I refactor a function and cut the codebase by 200 lines, I just earned less money. That's a broken dynamic.

There's also the anxiety it creates on the client side. Every email they send me, every question they ask, they're watching the meter run. That friction makes projects worse. Clients second-guess asking for clarification. They avoid scope conversations. Problems get buried until they're expensive.

What fixed pricing actually means

When I quote a fixed price, I'm saying: I've thought about this problem, I understand the scope, and this is what it costs to solve it.

That shifts the entire conversation from time to outcome.

The client stops thinking about hours and starts thinking about value. Is this feature worth €2,000? That's a business question — and it's the right question to be asking.

For me, it creates the right incentive: build it well and fast. Every hour I save is mine. Every clever solution that cuts complexity makes the project more profitable. I'm rewarded for being good at my job, not for being slow.

What it requires

Fixed pricing only works if the scope is defined upfront. Vague briefs produce bad quotes.

This is why I start every engagement with a Discovery call. Thirty minutes to understand what you're building, who it's for, and what "done" looks like. Not to upsell — to quote accurately.

A fixed price with a vague scope is just hourly billing with extra paperwork. I've seen freelancers abuse that structure. I don't.

When scope changes mid-project — and it sometimes does — we discuss it openly and agree on an adjustment before I build it. No surprises. No invoices that come in 40% over estimate because "the API integration turned out to be harder than expected."

The question clients always ask

"What if it takes you longer than expected?"

That's my problem, not yours. I've built enough projects to estimate accurately. When I'm wrong, I eat the difference. That's what the fixed price guarantees.

It's happened twice in three years. Both times I underestimated the complexity of a third-party integration. Both times I delivered at the quoted price anyway, because that's what the contract said and that's what builds a long-term working relationship.

The question clients should ask instead

"What if the scope needs to change?"

That's worth discussing upfront. Define a change request process before you start. Agree that anything beyond the original spec gets a separate quote and approval. Keep it simple and explicit.

Most projects don't change significantly mid-build if the Discovery phase was thorough. But having the process agreed means you handle the rare case without awkwardness.

Hourly billing in one situation

I do charge by the week for retainer and contractor arrangements — ongoing work with flexible scope where a fixed price per feature doesn't make sense.

But even then, I quote a weekly rate with a clear minimum commitment, not an open-ended meter running until someone blinks.

The underlying principle is the same: know what you're paying before you agree to it.

That's not a radical idea. It's just good business.