Traditional SaaS pricing breaks when you add AI to the equation. Not "needs adjustment" - breaks completely. And if you're building an AI-powered product, getting pricing wrong will kill you faster than a bad algorithm.
Mayank Pant from Stripe walked through why this happens and what to do about it in a recent talk. The core insight: SaaS pricing assumes predictable costs per customer. AI pricing depends on usage patterns you can't predict - and if you charge a flat subscription while your costs spike with usage, your margins evaporate.
Why Flat Subscriptions Don't Work for AI
Here's the problem in numbers. A traditional SaaS company might spend £5 per month per customer on infrastructure. Whether they're a light user or a power user, the cost variance is small. Your pricing can absorb that spread.
An AI company has a different problem. One customer might trigger 100 API calls per month. Another triggers 100,000. If you're paying per token to OpenAI or Anthropic, your cost per customer can vary by 1000x. A flat £50/month subscription works for the light user, loses money on the power user, and creates perverse incentives where your best customers cost you money.
The temptation is to solve this with rate limits - cap usage at some reasonable level and upsell heavy users to enterprise plans. But rate limits break user experience. Nobody wants to hit a wall mid-workflow because they exceeded their monthly quota. And enterprise sales cycles are slow - you can't wait three months to monetise your power users.
Usage-Based Pricing as a Solution
Pant's argument is straightforward: charge for what costs you money. If your costs scale with API calls, charge per API call. If they scale with compute time, charge per minute. If they scale with data processed, charge per gigabyte.
This does two things. First, it aligns your revenue with your costs. When a customer uses more, you earn more - and that additional revenue covers the additional cost. Your margins stay stable as usage scales. Second, it creates fair pricing. Light users pay less. Power users pay more. Nobody subsidises anyone else.
The objection to usage-based pricing is always the same: customers want predictable bills. They don't want to wake up to a surprise invoice because usage spiked unexpectedly. That's valid. But it's solvable.
Making Usage-Based Pricing Predictable
The key is transparency and control. Show customers their usage in real-time. Dashboard, email alerts, Slack notifications - whatever keeps them informed. Let them set spending limits or budget caps so they never get surprised. And give them tools to optimise usage - caching, batching, filtering - so they can reduce costs without reducing value.
Stripe's approach includes usage alerts: "You've hit 80% of your expected monthly spend. Adjust your usage or increase your budget." That single notification prevents the surprise bill problem. The customer stays in control. You stay profitable.
Another tactic: hybrid pricing. A base subscription for access, plus usage charges for consumption. This gives customers the predictability they want (the base fee) while keeping your margins safe (the usage component). It's not perfect - you're still subsidising some usage in the base tier - but it's better than pure flat pricing.
Choosing the Right Usage Metric
Not all usage metrics are created equal. Pant emphasises picking a metric that correlates with customer value, not just your costs. If you charge per API call but customers care about outcomes (reports generated, insights delivered, tasks completed), they'll feel nickled-and-dimed.
Good usage metrics are:
Simple to understand: "Per document processed" makes sense. "Per token with 1.5x multiplier for multimodal inputs" does not.
Aligned with value: Charge for what customers care about. If they care about speed, charge for priority processing. If they care about volume, charge per item.
Hard to game: If customers can manipulate the metric to pay less without reducing their usage, your pricing model has a leak. Charging per user fails when customers share logins. Charging per output works when outputs are auditable.
Implementation Challenges
Building usage-based pricing is harder than flipping a switch in Stripe. You need metering - accurate, real-time tracking of usage across every customer. You need billing logic that handles prorated charges, refunds, and adjustments. You need transparency tools so customers can monitor and control their spending.
For small teams, this is significant infrastructure work. Stripe's Billing product handles some of it, but you still need to instrument your application to track usage correctly. Miss a metering event, and you either overcharge (customer complaints) or undercharge (lost revenue).
The other challenge: customer education. Users trained on SaaS subscriptions expect flat monthly bills. Moving them to usage-based pricing requires explaining why it's better for them. Show them the maths. Demonstrate how a light user saves money. Prove that your alerts prevent surprise bills. Make the case clearly, or expect resistance.
When to Switch to Usage-Based Pricing
If you're pre-revenue, start with usage-based pricing from day one. It's easier to launch with the right model than to migrate later. Your early customers will adapt because they're early adopters - they expect experimentation.
If you're already charging flat subscriptions, the migration is trickier. Grandfathering existing customers on old pricing while moving new customers to usage-based creates complexity. But it's still worth doing if your margins are suffering. Run the numbers: how much are you losing on power users? How much would you gain by switching? If the gap is significant, migration is worth the pain.
The Bigger Principle
Pant's framework isn't just about AI companies. It's about aligning pricing with costs and value. Every time you build something where costs vary significantly by customer, flat pricing creates risk. Usage-based pricing solves that risk - but only if you implement it thoughtfully.
For builders: treat pricing as a core product feature, not an afterthought. Get it wrong, and you'll either bleed money or lose customers. Get it right, and your unit economics work at every scale. That's the difference between a business that survives its own success and one that doesn't.