Pricing Strategy · 12 min read
Usage-based pricing (UBP) — charging customers based on what they consume rather than a flat fee — aligns your revenue with customer value and removes the seat-count negotiation that slows enterprise deals. It works best for API products, infrastructure, and tools with measurable consumption units (API calls, messages sent, compute hours, transactions processed). It works poorly for collaboration tools, project management, and products where usage is hard to define meaningfully. Indian SaaS companies building API-first products should evaluate UBP early — Cashfree, MSG91, and Exotel have all built significant revenue on consumption pricing.
Usage-based pricing charges customers proportionally to their consumption of a measurable unit of your product's value. Twilio charges per SMS sent, per minute of voice call, per email delivered. Stripe charges per payment processed (as a percentage). AWS charges per compute hour, per GB of storage, per API call. The defining characteristic: revenue scales naturally with customer growth without requiring manual upsell conversations or contract renegotiations.
The structural advantage over seat-based pricing is profound: a startup that processes 1,000 API calls/month and a enterprise that processes 10 million API calls/month both pay amounts aligned with the value they're extracting from your product. There's no artificial seat count negotiation, no "we only need 20 seats but the plan minimum is 50" friction, and no underutilisation resentment when a company pays for 50 seats but only 30 people actively use the product.
The usage metric you choose determines everything: how easily customers can understand their costs, how aligned your revenue is with customer value, how predictable your revenue is, and how much customers limit usage to avoid costs. A bad metric choice can sink an otherwise good UBP model.
Criteria for a good usage metric: It must be easy for customers to predict and control (they can see their usage before the bill arrives). It must scale naturally with customer value (customers who get more value from your product consume more of the metric). It must be measurable without relying on customer self-reporting. And it must not create perverse incentives — metrics like "number of errors detected" could incentivise customers to create fewer integrations to reduce errors detected, undermining your product's value.
Common metric categories: Output metrics (messages sent, reports generated, documents processed) are most transparent — customers pay for outcomes. Input metrics (API calls made, data uploaded, records imported) are easier to measure but can feel arbitrary to customers. Outcome metrics (revenue processed, users reached, savings generated) are most value-aligned but often hardest to track.
For Indian SaaS: MSG91 charges per SMS/email/WhatsApp message delivered — a clear output metric. Cashfree charges a percentage of each transaction — an outcome metric directly tied to GMV. Exotel charges per minute of call connected — an output metric. All are transparent and predictable for the customer.
UBP almost always pairs with a free tier — a consumption allowance that lets customers start using and experiencing value without committing to payment. Twilio's free trial credits, Stripe's zero monthly fee with transaction fees only starting at first payment, Cloudflare's generous free bandwidth tier — these are all UBP + free tier structures. The free tier serves as the top of the PLG funnel: customer acquires themselves through free usage, finds value, grows, and naturally converts to paid as usage exceeds the free allowance.
Setting the right free tier size: generous enough that developers can build and test their integration without hitting limits (artificially low free tiers frustrate developers at exactly the moment they're evaluating your product), but not so generous that the median customer can build a production product without paying. The goal is for the free tier to cover development and low-volume production, with payment kicking in as usage scales to meaningful levels.
The hardest operational challenge of UBP is revenue predictability. Per-seat SaaS has highly predictable monthly recurring revenue — you know at the start of each month exactly how many seats are contracted and what the revenue will be. UBP revenue fluctuates with customer usage — if a customer has a slow month, your revenue from them drops. If they have a spike, your revenue spikes. This variance makes financial forecasting harder and investor communication more complex.
The mitigation strategies: committed spend tiers (customers pre-commit to a minimum monthly spend, often at a discount, which gives you a revenue floor); usage alerts and forecasting tools for customers (help them predict their bill, which helps you predict your revenue); and a mixed model where a base subscription covers core features with UBP add-ons for additional consumption (the hybrid approach used by Datadog, MongoDB, and most mature UBP SaaS).
Net Revenue Retention (NRR): The most important metric. NRR measures revenue from your existing customer base at the end of a period compared to the start, including expansion (usage growth), contraction (usage decline), and churn. A healthy UBP SaaS should have NRR of 110-130%+ — meaning your existing customers are spending more each year just by growing their usage. This is the compounding engine that makes UBP economically powerful. Expansion revenue: What percentage of your revenue growth comes from existing customers growing their usage vs new customer acquisition. Best-in-class UBP SaaS sees 40-60% of growth from expansion — growing with customers rather than constantly replacing churned ones. Usage-to-revenue lead time: How long does it take from a customer showing usage growth to that growth appearing in your revenue? This matters for cash flow planning.
Indian SaaS teams building UBP should account for some India-specific dynamics. Payment frequency expectations in Indian enterprise: Indian procurement often prefers annual invoicing with quarterly review rather than monthly auto-billing. Build the option for committed annual spend upfront, even in a UBP model, to match Indian procurement preferences. GST on usage-based billing requires careful implementation — make sure your billing infrastructure can correctly apply GST to consumption-based invoices, which vary monthly. Indian developer market sensitivity to pricing: Indian developers (the decision-influencers for API products) are highly price-sensitive and will actively evaluate competitors if your pricing feels higher than alternatives. Document your pricing clearly, provide a cost calculator, and be transparent about any per-unit cost changes.
Yes, but with careful metric selection. Notion charges per block stored (a usage metric for a collaboration tool). HubSpot charges based on the number of contacts in your CRM. Intercom has charged based on "people reached" (number of users your support team interacted with). Each of these takes a collaboration or CRM product and finds a usage metric that scales with customer value. The test: does a customer who gets more value from your product naturally consume more of this metric? If yes, it's a candidate for UBP. The challenge for non-API products is that usage metrics can feel arbitrary — "why am I being charged for contacts, not for the value of deals I closed?" — which requires careful framing and communication.
We help SaaS teams design pricing models that align with customer value and support sustainable growth. Book a free strategy session.
Book Free Strategy Call