Value-based pricing

Day 20: Price the alternative, not your effort

Ask an engineer to price something and they'll start estimating hours. That's the wrong number. Your first price tells customers what your work is worth, and if you build it from effort, you're building it from the one thing they never see. Coding agents have made building cheap, so this mistake now costs a lot more than it used to.

The moment it clicked for me

Back in my founder years, a customer mentioned in passing that our tool had saved them more in one month than we charged them for the whole year. They meant it as a compliment. On the train home I opened my notes app and did the maths. I'd set that price by estimating our build hours, adding a margin and rounding to something that felt polite. Not once had I asked what the customer would have lost without us.

Most engineers will know what came next. It wasn't regret, exactly. It was a quiet embarrassment: I'd charged for my effort, and they were paying for their outcome. I had priced the part I could see and ignored the part that mattered to them.

Why engineers default to cost-plus

Cost-plus pricing is simple. Take what it cost you to build and run the thing, add a margin, and call that the price. Engineers slide into it naturally because effort is the one number we've been trained to estimate. Story points, person-days, sprint capacity: every one of them measures our side of the table. We trust effort because we can see it.

Earlier in this series you learned to start from the user's problem and the job they hire your product to do. Pricing is where that thinking becomes money. The price comes from how big their problem is, not from how much effort you put in.

• ▹You see the effort. The customer doesn't. They never look at your sprint board.
• ▹When customers judge your price, they hold it up against what they'd do otherwise. Your build cost never comes into it.
• ▹Cost-plus feels fair and safe. Underneath, it assumes the customer's problem is the same size as your workload, and those two numbers have nothing to do with each other.

The 2026 twist: agents break cost-plus

With Claude Code, Cursor or a similar coding agent, the weekend build is real. A tool that used to take a small team a month can take one person two days. Great news for builders. Terrible news for cost-plus pricing.

Cost-plus logic:
  price = build_cost x margin

Before agents:  build_cost = 100 units  -> price = 100 x 1.5 = 150
With agents:    build_cost =  10 units  -> price =  10 x 1.5 =  15

Customer's problem in both cases: unchanged.
Customer's alternative in both cases: unchanged.
Your price: down 10x for no reason the customer cares about.

Tie your price to build cost and every jump in agent productivity cuts your price. Those jumps keep coming. Cost-plus slides steadily toward whatever it costs you to run the thing. Meanwhile the customer's spreadsheet still eats four hours a week, and the invoice errors still cost what they cost. Something cheap to build can still be very valuable to the person using it.

There's one force pushing the other way in the AI era. If your product runs on LLM inference, your floor isn't near zero any more. Every call burns tokens. So you've got a build cost that keeps shrinking and a running cost that's real and grows with usage. Know both numbers. Don't let either of them set your price.

The one model to keep: three numbers on a line

If you keep one thing from today, keep this sketch. You can redraw it on a whiteboard in ten seconds.

• ▹Floor = your cost: hosting, inference, support, and your time to maintain it. Go below it and you lose money. Treat it as a line you stay above, never as the place your price starts.
• ▹Ceiling = the customer's next-best alternative. Maybe that's the spreadsheet plus someone's hours. Maybe a competitor's product, a contractor, or doing nothing and living with the pain. Price above it and a rational customer walks to the alternative.
• ▹Value = what solving the problem is worth to them, and it's often higher than the ceiling. You usually can't capture it, because the alternative caps what they'll pay. It still tells you how much the problem hurts.
• ▹Your price goes between floor and ceiling, nearer the ceiling. Leave a clear gap under the alternative so switching is obviously worth it, hassle included.

Here's what makes this model useful: when your build cost falls, the ceiling stays put. Agents push your floor down. Your build cost does nothing to the customer's alternative. (Competitors getting cheaper can move it, which we'll get to under the limits below.) Anchor to the alternative, and cheaper building becomes margin for you rather than a discount for them.

Worked example: a two-day agent-built tool

Say you use an agent to build an invoice reconciliation tool in two days. It reads supplier invoices, matches them against purchase orders, and flags mismatches and duplicates. You might sell it to small businesses, or pitch it as an internal tool to another team. The numbers below are illustrative, so swap in whatever your real customer tells you.

Step 1: List the real alternatives. Ask what they do today. Don't guess.

• ▹Status quo: a spreadsheet plus about 4 hours a week of an ops person's time, and every so often a duplicate payment slips through.
• ▹Competitor: an accounting add-on at, say, $400/month. It doesn't fit their PO format, so someone still spends about 1 hour a week checking by hand.
• ▹Contractor: a freelancer builds something custom for a one-off fee. Then nobody maintains it.
• ▹Do nothing: keep paying the odd duplicate invoice. This is often the true competitor, so give it a number as well.

Step 2: Turn each alternative into a monthly number.

Assumptions (replace with real ones from customer conversations):
  Ops person loaded cost:  $50/hour
  Weeks per month:         ~4.3

Status quo:
  4 h/week x 4.3 x $50              = ~$860/month  (plus error risk)

Competitor:
  $400 subscription
  + 1 h/week x 4.3 x $50 = ~$215
                                    = ~$615/month

Next-best credible alternative (ceiling): ~$615/month

Your floor:
  hosting + LLM inference + support  = ~$40/month per customer (estimate)

Build time: 2 days  -> NOT IN THE CALCULATION

Step 3: Land a price. Floor is about $40. Ceiling is about $615. Charge somewhere around $250 to $300 a month and the customer saves roughly half compared with their best alternative. That's a clear reason to switch, and you're still sitting far closer to the ceiling than to your cost. Cost-plus might have had you charging $60. Same tool, same customer, and a lot of money left on the table.

Look for the "two days" in that calculation. It isn't there. The customer doesn't know how long the build took, and they shouldn't need to. Two months of work? Same price. An agent knocking it out in two hours? Still the same price.

Where this bites inside a company

You don't have to be a founder to make this mistake. Engineers make it every week, just by describing their work in terms of effort:

• ▹"It's a small change" tells your PM it's cheap. It says nothing about whether it matters. Compare: "This removes the step that causes most of our onboarding drop-off." Same change, described by its value.
• ▹Prioritisation used to be value divided by effort, with effort doing most of the work. Agents shrink the effort term, so now value decides. If you can't say which problem a feature removes and what that problem costs, you can't argue for it.
• ▹Your own performance review counts too. "Shipped 14 PRs" is cost-plus thinking. "Cut support tickets on X, which had been eating a support engineer's afternoons" is value thinking.
• ▹With internal tools, the alternative is usually people's time or a vendor contract. Put a monthly number on it and your tool stops being a nice side project and becomes a line on the budget.

Honest limits

• ▹You can't work out the alternative from your desk. Value pricing only works once you've actually talked to customers about what they do today and what it costs them. That's the discovery work from earlier in the series. Skip it and your ceiling is made up.
• ▹Agents cut your competitors' build costs too. Someone can rebuild your weekend tool next weekend. If they price it low, the customer's alternative drops, and your ceiling drops with it. The code isn't your moat. Knowing the problem better than they do is: the edge cases, the workflow, the trust you've built.
• ▹More and more customers assume anything AI-built should be cheap. You'll hear it. Answer by talking about their alternative, never your effort.
• ▹Value is hard to measure. Counting hours saved is easy. Risk avoided and faster decisions are much harder. Don't fake precision you don't have. Use ranges.
• ▹Where I'd still trip up: underpricing because I'm scared of hearing no, assuming the alternative instead of asking, and forgetting that doing nothing is usually the real competitor. I've done all three.

Day 20 exercise

Pick one thing you've built. A feature, an internal tool, a side project, anything. Write down three numbers:

• ▹1. What it cost to build (and to run per month, including inference).
• ▹2. What the user would do without it, in one sentence.
• ▹3. What that alternative costs them per month, in money or in hours turned into money.

Now check your current price, or the way you pitch this work to your PM or manager. Is it closer to number 1 than to number 3? Then rewrite it so it starts from the alternative. Day 21 moves from the number to the conversation: how to test a price or pitch with real users before you commit to it.

Extend your knowledge

• ▹"Don't Just Roll the Dice" by Neil Davidson: a short, practical book on software pricing from someone who founded a software company.
• ▹"Monetizing Innovation" by Madhavan Ramanujam and Georg Tacke. Focus on the chapters about discussing willingness to pay before you build.
• ▹Patrick McKenzie's (patio11) essays on why software builders should charge more, on his blog Kalzumeus.
• ▹Run the three-number exercise on the last feature you shipped, then pitch it to your PM using only number 3.