There is an uncomfortable arithmetic at the centre of AI-assisted development. If the work that took forty hours now takes twenty, and you bill hourly, you have just halved your income for the same delivered outcome. Getting faster made you poorer, which is a strange result for an improvement.
The response people reach for first is to keep quiet about it and bill the old number, which is dishonest and also unstable — clients are not unaware that tooling has changed, and a rate that depends on them not asking is a rate with a short life.
The stable answer is to stop selling hours. That sounds like a platitude until you work out what you are actually selling instead, how to price it, and what to say when somebody asks whether AI wrote the code. This post is about those three things.
Why does hourly billing break here?#
Because it prices the input, and the input is exactly what changed.
An hourly rate is a claim that your time is the scarce resource being purchased. When a tool halves the time required to produce the same result, that claim quietly stops describing reality — the scarce thing was never the typing, it was knowing what to type and whether the result is correct.
The deeper problem is that hourly billing puts you and the client on opposite sides of every efficiency. They want it done faster; you are paid for it taking longer. That tension is manageable when improvements are incremental and becomes untenable when a tool arrives that changes the number substantially.
| Model | Prices | Effect of getting faster |
|---|---|---|
| Hourly | Your time | You earn less |
| Day rate | Your availability | Neutral, if utilised |
| Fixed scope | A defined outcome | You earn more |
| Value-based | The result to them | Decoupled entirely |
| Retainer | Reserved capacity | You deliver more per month |
Only the first row punishes improvement, and it is the one most freelancers start with because it is the easiest to explain. The move away from it is not about extracting more — it is about aligning the incentive so that working out a faster way to do something is not self-defeating.
The client is not buying hours either#
Nobody wants forty hours of development. They want a working booking system, a store that converts, a migration completed before a contract expires. Hours are a proxy that both sides tolerate, and dropping the proxy usually makes the conversation clearer rather than more difficult.
What are you actually selling?#
Judgement, ownership and a working outcome — none of which got faster.
This is the part worth being precise about, because "you are selling value not time" is unhelpfully vague. Concretely, what a client gets that AI does not provide is the decision about what to build, the architecture that will still make sense in a year, the review that catches the subtly wrong output, and somebody accountable when it breaks at 2am.
Deciding what not to build#
A large part of the value in any project is the feature that was talked out of scope because it would have doubled the timeline for marginal benefit. Faster typing does not produce that judgement, and it arguably makes it more valuable — when building is cheap, the discipline of not building is what protects the timeline.
Architecture that survives#
Generated code is locally reasonable and globally indifferent. It does not know that this table will be queried by a report nobody has written yet, or that this integration will need to run twice. Someone has to hold the whole shape in mind, and that has not been automated.
The review that catches the subtle bug#
The failure mode of AI-assisted code is not obvious breakage — it is plausible code that is wrong in a specific case. Catching that requires knowing what to look for, and it is the least visible and most valuable part of the work.
Accountability#
A client is buying somebody who is responsible for the outcome. That responsibility has no faster version, and it is the thing that distinguishes a professional engagement from a tool subscription.
How do you actually price a fixed-scope project?#
From the value and the risk, informed by effort rather than derived from it.
The practical method is to estimate the work honestly, including everything around the code, then set a price that reflects what the outcome is worth and what you are carrying in risk. The estimate tells you the floor; it does not determine the number.
- Break the work into components you have built before, and estimate each.
- Add the non-code work — setup, testing, review cycles, deployment, handover.
- Add contingency for the named unknowns, stated rather than hidden.
- Consider what the outcome is worth to the client, which sets the ceiling.
- Price within that range according to risk, certainty and how much you want the work.
Step four is the one people skip, and it is the difference between a rate and a business. A migration that unblocks a contract worth six figures is not priced the same as a marketing site, even if the effort is similar — and clients understand this intuitively because it is how they price their own work.
Risk belongs in the price#
Fixed-scope pricing means you carry the overrun risk, and that risk has a value. A well-understood build with a clear boundary carries little; one depending on an undocumented third-party system carries a lot. Pricing them the same means the second one subsidises nothing and eventually costs you.
Do not quote your hourly rate times the hours#
It is the natural instinct and it recreates the problem in a different format. If a fixed price is just a disguised hourly estimate, the incentive is unchanged and you have added risk without adding margin.
Be prepared to walk away from the number#
A price you resent is a price that produces resentful work. Setting a number you are genuinely happy with, and being willing to lose the project at it, is what makes the whole model function — and declining is a legitimate outcome.
What do you say when they ask about AI?#
The truth, framed accurately — which is a better answer than either extreme.
Clients do ask, and the two tempting replies are both wrong. Denying it is dishonest and increasingly implausible. Leading with it — positioning yourself as an AI-powered service — invites the response "then why does it cost this much", and it sells the tool rather than the person.
The honest framing#
AI writes a lot of the boilerplate; I own the architecture and the review. That is accurate, it is easy to say, and it locates the value correctly. Clients are not confused by this — they use the same tools and know perfectly well that output still needs somebody responsible for it.
Always attach the counterweight#
Every speed claim needs its honest limit stated alongside it, and this is the version I use: what AI does not change is that someone still has to own the architecture, catch the subtle bug, and say no to the feature that will sink the timeline. That part is still me — the tooling just means you pay for judgement instead of typing.
Speed is a benefit to sell, not a discount to offer#
Getting a working product in three weeks instead of eight is worth something to the client — earlier revenue, earlier learning, an earlier decision about whether to continue. That is a benefit you are delivering, and framing it as a reason to charge less gives away the thing you improved.
Do not claim what you cannot deliver#
An MVP in nineteen days is a real outcome under specific conditions — a clear scope, an available decision-maker, no dependency on somebody else's legacy system. Presenting that as a general promise sets up a failure. The claim needs its conditions attached or it becomes a liability the first time they are not met.
How do the engagement models differ?#
Three shapes, matched to how certain the work is rather than to how large it is.
| Engagement | Suits | Shape |
|---|---|---|
| Fixed-scope sprint | One clear outcome, well understood | 1–2 weeks, fixed price |
| Product build | An MVP or application with a real launch date | 3–8 weeks, fixed scope |
| Ongoing partner | Continuous work, shifting priorities | Monthly, rolling |
The mistake is choosing by size. A large, well-defined build fits fixed scope comfortably; a small piece of exploratory work does not, and forcing it there produces either a padded price or an overrun. Certainty is the variable that should decide it.
Retainers price capacity, which is honest#
An ongoing arrangement reserves a slice of your week, and what the client buys is availability and accumulated context. Neither of those is affected by tooling speed — if anything they improve, because more gets delivered inside the same reserved capacity.
Retainers need a defined shape#
An unbounded monthly arrangement becomes either an unpaid emergency service or an awkward conversation about whether enough was delivered. Stating what the retainer covers, roughly how much capacity it represents and what falls outside it keeps it working for both sides.
Does this mean charging more?#
For the same outcome delivered faster, often yes — and that is the part people find difficult.
The instinct that faster work should cost less is strong and it comes from an hourly worldview. Once the thing being sold is an outcome, the delivery time is a feature of the service rather than a component of its cost, and a faster outcome is a better service.
The market sets the ceiling, not your effort#
What a client will pay is a function of what the result is worth to them and what alternatives cost. Your internal efficiency does not enter that calculation, and volunteering it as a reason to reduce the price is a negotiation against yourself.
Efficiency gains are yours to keep, up to a point#
A carpenter with better tools does not charge less for a door. But if a category of work becomes dramatically cheaper across the market, prices do move, and pretending otherwise is a slow way to become uncompetitive. The realistic position is that you keep the gain until the market reprices, and you notice when it starts to.
Where speed genuinely should reduce the price#
For commodity work — a template site, a standard integration — competing on price is the market and the honest move is to price accordingly or not take it. The distinction is whether the client is buying a known deliverable or a judgement call, and only the second supports a premium.
What about the cost of the tools?#
Real, and small enough that it is not the interesting part.
Subscriptions, API usage and the occasional expensive experiment are a genuine business cost, and on projects with heavy AI features the usage cost can be material. It should be in your pricing as an overhead, and where a project involves running models at scale, it belongs in the quote explicitly rather than absorbed.
Pass through variable inference costs#
When a build includes a feature that calls a model per user action, that is an ongoing operational cost the client will carry. Estimating it during scoping and stating it plainly avoids a surprise on their first bill — and cost logging belongs in the build so the number is observable rather than theoretical.
Do not price your own tooling into line items#
Your editor, your assistant subscription and your infrastructure are overheads like any other. Itemising them invites a conversation about whether the client should buy them directly, which is not a conversation worth having.
How do you handle a client who wants the discount?#
By moving the conversation from cost to outcome, once, and then holding the number.
"You are using AI, so it should be cheaper" is a reasonable thing for somebody to say and it deserves a straight answer rather than defensiveness. The answer is that the price reflects the result and the responsibility, and that the speed is what they are getting rather than what they are subsidising.
Offer a smaller scope, not a lower price#
Reducing the price for the same deliverable sets a precedent and devalues the work. Offering a reduced scope at a lower number keeps the rate intact and gives them a genuine choice, and it often surfaces that half the scope was not needed.
Some clients are not your clients#
A buyer whose primary criterion is cost will find somebody cheaper, and chasing them means competing on the one dimension where you cannot win sustainably. Letting them go is a decision rather than a failure.
What does it cost?#
Some lost deals, and a period of discomfort while you adjust.
Moving from hourly to fixed pricing means carrying overrun risk, quoting numbers that feel high the first few times, and losing some work to cheaper alternatives. That is the transition cost and it is real, particularly in the first few months while your estimates are still calibrating.
The honest counterweight: fixed pricing genuinely transfers risk to you, and if your estimates are poor it transfers it painfully. Hourly billing is not merely a worse model — it is a safer one for work you do not understand well, for a client relationship that is new, and for anybody early enough in their practice that estimates are still unreliable. The right move is to fix the price on work you have done before and bill by time or in stages on work you have not, rather than adopting one model everywhere because it is theoretically superior.
If you bill by the hour and the hours halve, you have given yourself a pay cut for getting better at your job.
Conclusion#
Hourly billing prices the input, and the input is exactly what AI changed. It also puts you and the client on opposite sides of every efficiency, which is manageable while improvements are incremental and untenable once a tool halves the number. The stable answer is to price outcomes instead.
Be precise about what you are actually selling: deciding what not to build, architecture that survives contact with next year, the review that catches plausible-but-wrong output, and somebody accountable when it breaks. None of those got faster, and the first arguably got more valuable — when building is cheap, restraint is what protects the timeline.
Price fixed-scope work from a floor set by honest estimation and a ceiling set by what the outcome is worth, positioning within that range according to the risk you are carrying. Do not quote your hourly rate multiplied by hours, because that recreates the same problem with added risk.
When clients ask about AI, tell them the truth with the counterweight attached — it writes the boilerplate, you own the architecture and the review, and what has not changed is that somebody has to catch the subtle bug and say no to the feature that would sink the timeline. Sell speed as a benefit rather than offering it as a discount.
Match the engagement model to how certain the work is rather than how large: a fixed-scope sprint for a clear outcome, a product build for something with a real launch date, a retainer for continuous work. And be honest about where fixed pricing does not fit — new relationships and unfamiliar work are safer billed by time. If you want to talk about a project on that basis, start here.