Imagine a builder quoting for an extension. They arrive, look at the site, ask what you want, and say: “I will work hour by hour at sixty quid an hour, and I will let you know when it is done.” You would walk away. You would assume they did not know what they were doing, or worse, that they were planning to spin it out.
Yet that is exactly how most software gets billed. Hourly. With a fuzzy estimate at the start, a fuzzier number at the end, and a long argument in the middle about what counts as billable.
Hourly billing aligns the wrong incentives.
When you bill hourly, the incentive is to take longer. Every hour you save is an hour you do not bill. Every clever optimisation, every reused component, every piece of work that came together quickly because you have done it before — all of that costs you, in revenue terms.
Good consultants resist this incentive. They take the speed-up and absorb the lost revenue. Bad consultants follow it. Either way, the incentive is pointing in the wrong direction, and incentives shape behaviour over time.
Worse, hourly billing penalises your craft. The better you get, the less you earn per project. Fifteen years of experience is supposed to compound into faster, better outcomes — and on hourly billing, it compounds into smaller invoices.
“Hourly billing penalises craft. The better you get, the less you earn per project.”
Fixed-price moves the risk to where it belongs.
When I quote a fixed price, I am taking on the delivery risk. If it takes me longer than I estimated, I eat the difference. If it takes me less time, I keep the difference. The client gets a clear number up front, and the conversation is about scope, not hours.
This is the right shape because I am the person who can manage that risk. I am the one who knows my speed, my tooling, my standard patterns, and what is going to bite. The client cannot manage that risk — they have no visibility into my codebase or my workflow. Asking the client to bear delivery risk via hourly billing is asking them to bear a risk they cannot price.
The trade-off is that I have to scope properly. Cheap fixed-price quotes from people who have not thought hard about the work are how horror stories happen. A good fixed-price quote is the output of a real discovery process — written, agreed, and clear about what is in and what is out.
What changes in the conversation.
Once we have agreed a fixed price for an agreed scope, the conversation becomes pleasant. The client never has to wonder if a phone call is going to cost them. They never have to time-police me. I never have to time-police myself.
Scope changes are explicit. If something genuinely new comes in mid-project, we have a separate small change-order conversation. The vast majority of small adjustments — copy tweaks, design polish, a tweak to a workflow — get absorbed into the existing fixed price without anyone counting.
The relationship moves from transactional to collaborative. Both sides are now aligned on outcomes: the client wants the project done well; I want the project done well and shipped, so I can free up to take the next one.
- →No timesheet theatre
- →No clock-watching mid-call
- →No hidden incentive to drag the project out
- →Risk priced once, by the person who can actually manage it
- →Conversation becomes about scope and outcomes, not hours
How I actually quote.
Discovery first, always. I will not quote on a one-line brief. I want a written problem definition, technical constraints, the integrations involved, and a clear definition of done. Discovery itself is a small fixed-price piece of work.
After discovery, I quote a single number. Not a range, not a band, not a “starting from”. One number, with the scope it covers attached as an appendix. The scope is short and specific.
Payment is split into milestones. Typically a deposit on signing, an interim on a defined demo, and a balance on launch. That is enough structure to keep both sides honest, without turning the engagement into a billing conversation.
And finally — because this is the bit people forget — I include a real definition of post-launch support. Thirty days as standard, with bug fixes covered. Beyond that, an explicit retainer or pay-as-you-go option. Vague support promises are how relationships sour.
When fixed-price does not work.
Genuinely exploratory R&D. If neither of us knows what we are building yet, fixing the price is dishonest. For these I run a time-boxed discovery instead — “two weeks, fixed price, output is a written direction” — and then we either commit to a fixed price for the build, or we part ways amicably.
Long retainers for ongoing maintenance. These are better priced as a flat monthly fee with a defined response SLA. Same idea — fixed price for fixed scope — just stretched over time.
Anything where the client genuinely wants to be billed by the hour, often because they are buying capacity rather than outcome. I will do this for the right relationship, but I am clear up front that the billing model is suboptimal and we both know it.
“A good fixed-price quote is the output of a real discovery process — not a guess wrapped in confidence.”