The Problem Hourly Pricing Created
For years I charged by the hour, and it felt fair. Then I got good with Claude Code, and 'fair' turned into a trap. Work that used to take me two days started taking an afternoon. The client got the same result - often a better one - but my invoice shrank because the hours shrank. I had spent real effort getting faster, and my reward was earning less for delivering the same thing. That's not a bug in my rate. It's a flaw in the entire model.
Hourly pricing ties your income to your inefficiency. It quietly punishes every improvement you make. The faster and more skilled you get - exactly what a tool like Claude Code makes possible - the worse hourly serves you. I could either pretend to work slowly to protect my rate, which is dishonest and miserable, or change how I priced. I changed how I priced.
The Shift: Price the Outcome, Not the Hours
What I do now is quote one price for the outcome the client wants, independent of how long it takes me to build. If a client needs a system that sorts their inbound leads automatically, I price what that result is worth to their business - not the hours I'll spend making it. Whether Claude Code helps me finish it in a day or a week is my concern, not theirs. They're buying the result. I charge for the result.
I call this the Outcome Price, and the mental shift is bigger than it sounds. Under hourly, every efficiency gain leaks to the client. Under outcome pricing, getting faster increases your effective rate instead of cutting your pay. You're finally rewarded for skill instead of penalized for it. And the client is happier too, because they know the total up front with no meter running and no incentive for you to pad hours.
How I Actually Set the Number
Pricing the outcome doesn't mean guessing. It means anchoring on what the result is worth to the client, then sanity-checking that it's a good deal on both sides.
- Understand the value of the outcome. What does solving this actually do for the client - time saved, revenue unlocked, a cost removed? The discovery conversation is where you learn this. The price lives in relation to that value, not your hours.
- Set a price that's a clear win for them relative to that value. If the result saves them far more than it costs, the yes is easy and you're still well paid. Outcome pricing works because both sides come out ahead.
- Sanity-check the floor. Roughly estimate the effort so you know the price isn't below what the work costs you. This is a private check, not a line item you show the client.
- Quote one number tied to the result. No hourly breakdown, no timesheet. One price for the outcome, stated plainly.
The effort estimate stays behind the curtain. It stops you from underpricing, but it never becomes the thing you sell. The client sees a result and a price. How you get there - and how much Claude Code accelerates it - is yours.
Making the Switch Without Scaring Clients Off
The fear that stops most people is that clients will balk at a flat number after being used to hourly. In my experience the opposite is true: clients prefer knowing the total. Hourly makes them nervous - an open meter with no ceiling and an incentive for you to go slow. A single outcome price removes all of that. The key is how you frame the conversation.
- Talk about the result, never your speed. The moment you justify a price by how fast you work, you've re-anchored the whole conversation on hours. Stay on the outcome.
- Present the price as certainty for them. 'You'll know the full cost up front, no surprises' is a benefit clients actively want. Sell the predictability.
- Don't apologize for finishing quickly. If you deliver in three days, that's a feature - they got their result fast. It is not a reason to discount.
The Honest Tradeoffs
Outcome pricing is not free of downsides, and I'd be lying to pretend otherwise. It puts the estimation risk on you. If you badly misjudge the effort, you eat the difference - the client's price doesn't move because your build got messy. That's the real cost of the model, and it's why the private effort check matters.
Hourly vs outcome pricing, honestly
| Hourly | Outcome |
|---|---|
| Getting faster shrinks your invoice | Getting faster raises your effective rate |
| Client watches a meter with no ceiling | Client knows the full cost up front |
| Estimation risk sits with the client | Estimation risk sits with you |
| Rewards slow work | Rewards skill - but punishes bad scoping |
For me the trade is worth it many times over. The risk of the occasional misjudged scope is small next to the daily reality of hourly quietly taxing every improvement I make. But go in clear-eyed: outcome pricing pays you for getting good, and charges you for scoping badly. Scope carefully and it's the better model by a wide margin.
Try It on Your Next Quote
You don't have to convert your whole business overnight. Take one upcoming project and quote it as an outcome instead of an hourly estimate. Figure out what the result is worth to the client, set a price that's a clear win for them, privately check it clears your effort floor, and put one number on the page. Watch how the conversation changes when you're selling a result instead of your time.
Short, practical drops on skills, MCP, agents, prompts, and more. No spam, unsubscribe anytime.
Frequently asked questions
Why is hourly pricing bad for AI builds?
Because it ties your income to your inefficiency. As you get faster with a tool like Claude Code, work that used to take days takes hours - the client gets the same result but your invoice shrinks. You spend real effort getting better and your reward is earning less for the same outcome. Hourly pricing quietly punishes every improvement you make, which is backwards.
What is outcome-based pricing?
It's quoting one price for the result the client wants, independent of how long it takes you to build it. Instead of charging for hours, you charge for the outcome - what solving the problem is worth to the client's business. Whether Claude Code helps you finish in a day or a week is your concern, not theirs. Getting faster then raises your effective rate instead of cutting your pay.
How do I set an outcome-based price?
Anchor on the value of the result to the client - time saved, revenue unlocked, cost removed - which you learn in the discovery conversation. Set a price that's a clear win for them relative to that value, privately sanity-check that it clears the effort the build will cost you, and quote one number tied to the result. The effort estimate stays behind the curtain so you don't underprice, but you never sell hours.
Won't clients balk at a flat price instead of hourly?
In practice most prefer it. Hourly makes clients nervous - an open meter with no ceiling and an incentive for you to work slowly. A single outcome price gives them certainty about the total up front, which is a benefit they actively want. The key is to frame the conversation around the result and the predictability, never around how fast you work.
What's the downside of outcome-based pricing?
It moves the estimation risk onto you. If you badly misjudge the effort, you eat the difference - the client's price doesn't change because your build got messy. That's the real cost of the model and why a private effort check matters before you quote. Outcome pricing pays you for getting good and charges you for scoping badly, so scope carefully and it's the better model by a wide margin.
Last reviewed by Duncan Rogoff on July 28, 2026
