Pricing by the meter, part 1: why seats break for API products
Seats charge for people. An API costs you per call, per gigabyte, per job. Price the way your costs move.
Seat pricing works when value grows with headcount. A design tool with ten designers gets about ten times the value of one. An API doesn’t work that way. One engineer can wire your API into a product that calls it forty million times a month, and your costs follow the calls, not the engineer.
Three ways seats break
Your margins move without you. A customer on five seats who triples their traffic triples your compute bill. Their invoice stays the same.
Your best customers look like your worst. The account that sends 2M events a month and the one that sends 20,000 pay the same, so you can’t tell from revenue who depends on you.
Customers ration access. When every seat costs money, teams share one login. Fewer people see your product, and fewer people argue for it at renewal.
What to charge for instead
Charge for the unit your customer already thinks in, and that tracks your cost:
- API calls, for a search or enrichment API.
- Gigabytes stored or transferred, for storage.
- Jobs or minutes, for compute.
- Monthly active users, when value still follows people.
The test: can your customer predict next month’s bill from their own dashboards? If they can, the metric is a good one.
What changes in billing
Usage pricing needs three things seat pricing doesn’t: a record of every billable event, a way to count those events per customer per period, and an invoice your customer can check line by line. That’s metering, and it’s what part 2 covers: choosing your billable metric, with a worked example at 1.4M events a month.