Howdy pricing people!
Huge thanks to everyone who joined our latest Office Hours, and a big thank you to of Willingness to Pay for answering 30+ of your questions on one of the messiest topics in pricing right now: what to charge for when the thing using your product might be a machine. The whole session basically resolved to one distinction — are you pricing the door, or the work that goes through it? Breaking down my 5 top takeaways below for those who couldn't make it:
1️⃣ Don't price the door. Price what gets carried through it.
Your API, your own interface, and an MCP endpoint are all just doors into your product. The mistake Ulrik sees teams about to make is pricing the door — charging for the privilege of connecting, as if the connector were the product. It isn't. The value is whatever the customer carries out through it, and that's the thing you meter. The practical upshot: don't build a separate price list per channel, or you'll re-run this entire exercise the day you ship the next door. Pick one underlying value metric and let every channel — interface, API, MCP — debit the same thing. As Ulrik put it, meter the water, not the tap.
2️⃣ Decide whether you're selling an input or an outcome.
This is the fork everything else hangs on. An input is a token, a call, raw access — you price it like a utility, thin and on volume, like electricity. An outcome is a job the customer actually wanted done — and you price that on its value. The cleanest example he gave: Intercom charging for a resolved support ticket rather than a message, at a fraction of what a human resolution costs. The customer knows exactly what they got and exactly what it was worth. Tokens are where you start, not where you finish — and if you contract your price to the compute bill, every future cost saving belongs to your customer instead of you.
3️⃣ Wrap it in a unit the buyer can actually budget.
Nobody budgets tokens. Raw MCP calls are a dense, technical metric your buyer can't forecast and your salesperson can't explain, which turns every renewal into a physics lecture. Put credits (or whole workflows) between your raw usage and the invoice, keep the dollar-to-credit ratio simple enough to do in your head, and carry the per-call complexity in the terms where it belongs. And if you already run credits for in-platform AI — don't build a second economy for MCP. One wallet, one unit, debited wherever the work happens. If an agent costs more to serve for the same job, put that in the credit weight of the action, not a separate subscription the customer has to reason about.
4️⃣ Treat agents as machine-scale users, because they are.
Mechanically, MCP and a traditional API are nearly identical — a call is a call. The difference is who's on the other end and how fast they go. A human clicks a button twice a second and gets bored; an agent clicks it a few thousand times a second and never does. So the metric can look the same while the variance explodes. Ulrik's framing: treat MCP like an API whose user drank a thousand espressos — same metric, much harder limits. Instrument agent traffic separately from human traffic, reflect any extra cost-to-serve in the credit weight, and cap the downside.
5️⃣ Unlimited is a promise to humans — never to their agents.
Usage-vs-unlimited swings back and forth every few years, but it feels harder this time for a real reason: the cost of "unlimited" is now both large and unpredictable, and it scales with a non-human user that doesn't self-regulate. Ulrik's stance — he's not anti-unlimited, he's anti-unprotected. Sell the simplicity of unlimited on the front of the box if it wins deals, but put a fair-use limit in the contract set where 95–98% of customers never touch it. And get clear on what that limit is actually doing: a monetization threshold (hit it, pay more), a variance control (smooth a spiky metric), or a safety stop (so one customer can't take down the platform). The same number set for the wrong job will either leak money or start a fight.
The one map to keep from the whole session: cost sets your floor, the value chain sets your metric, and the buyer's budget sets your unit.
Thanks again to Ulrik and to everyone who showed up with such sharp questions — this was a good one. Attaching a summary report, and linking to the Google Drive folder with full recording and transcript for anyone interested. See you at the next one!
Rob