AI products need pricing that accounts for unpredictable compute costs and the margin risk from power users.
2
Hybrid pricing combines a predictable base fee with usage-based charges, giving customers room to experiment while protecting margins.
3
Pricing should start as a hypothesis, then change as product features, customer value, and infrastructure costs change.
Summary
Mayank Pant argues that traditional SaaS pricing breaks down for AI products because compute costs vary widely and a small group of power users can consume most of the available capacity. He recommends starting with the value customers perceive, then choosing a charge metric that expresses that value in understandable terms. Consumption, workflow, and outcome metrics each have different tradeoffs. Pant's preferred model is hybrid pricing, with a base fee plus a scaling usage fee. He also recommends credits, usage caps, notifications, top-ups, and rate limits so customers are not surprised by invoices. Pricing should be treated as a hypothesis and tested through customer conversations and A/B tests. The billing infrastructure must support frequent changes without months of engineering work. Pant presents Stripe Billing, Metronome, and related Stripe services as infrastructure for subscription, usage, hybrid, and enterprise pricing models.
AI margins make pure subscription and pure usage pricing difficult
Pant says AI products have lower margins than traditional SaaS, and those margins change with usage. Between 5% and 10% of users can consume 80% of compute, creating risk for a flat subscription. Infrastructure costs are also unpredictable. A pure usage model creates a different problem because customers may hesitate to explore a product when they cannot predict the invoice. Technical units such as tokens and API calls can also confuse buyers. Pant gives Gamma as an example: a customer cares about the number and quality of decks produced, rather than how many API calls were needed.
Frequent pricing changes can follow product growth
Pant describes the first price as a hypothesis rather than a permanent commitment. AI products add features quickly, and a feature that is premium today may become standard within six months. He says companies with more than 100% year-on-year growth changed pricing three or more times in the previous two years, while 22% of low-growth companies did so. He presents pricing iteration as something that should be built into the company's infrastructure. Waiting for a perfect price for a year can leave pricing behind the product.
Pant's first step is to define the value the customer believes the product provides. He groups that value into automation, augmentation, enhanced service, and improved results. Automation can save time and reduce cost. Augmentation lets the same people produce better work. Enhanced service can provide access to proprietary software or data. Improved results can connect directly to a business result, such as Intercom charging for tickets solved without human help. The charge metric should follow this perceived value rather than the internal mechanics of the product.
Charge metrics should express value in a customer-friendly unit
Pant distinguishes consumption-based, workflow-based, and outcome-based metrics. Infrastructure products may charge for API calls because that matches their cost structure. A workflow product might charge for generated images or summarized documents. An outcome-based product could charge for qualified leads, candidates put forward, or candidates hired. Consumption pricing is easier to implement, while outcome pricing can align more closely with customer value. Outcome pricing is harder to attribute and sell, so Pant says data is needed to support the connection between the charge and the result.
Credits can hide implementation changes while keeping pricing understandable
Pant recommends translating value into credits. A company might sell 100 credits per month and define internally what those credits buy. This gives customers a unit they can understand while allowing the company to change the underlying mix of API calls, image generations, or other features. He says credits can also prevent every feature change from directly changing the customer-facing price. In the question period, he explains that a premium feature can become standard while new features are added underneath the same credit system.
Hybrid pricing balances predictable revenue with usage protection
Pant contrasts subscription fees with usage fees. Subscription pricing creates predictable revenue and a committed customer relationship, but power users can damage margins. Usage pricing scales with customer activity and protects margins, but customers may avoid experimenting because they do not know the eventual cost. His hybrid model combines a base fee with a scaling fee. The base establishes the relationship, while the usage component lets customers try more of the product and pay for the value they use.
Pant says a wrong or unexpectedly high bill can destroy customer trust after months of good work. He recommends usage caps, such as stopping usage after a customer's credits are consumed unless the customer pays for more. Automated notifications at 50%, 70%, and 90% of a limit give customers time to respond. They can manually top up, enable automatic top-up, or wait for the next month. Rate limiting can stop faulty code from consuming the whole allowance. These controls give customers more control over flexible pricing.
Pricing experiments need billing infrastructure that can change quickly
Pant's fifth step is iteration. Companies should launch a price they believe is reasonable, ask customers who churn why they left, and separate product-market-fit problems from price problems. They can also ask upgrading customers similar questions and run pricing A/B tests. Credits allow companies to change the meaning of a package under the hood as features evolve. Pant says billing infrastructure determines how fast this process can move. If every pricing change takes three or four months of engineering work, frequent iteration becomes impractical.
