Determining the price of digital products is not just about choosing a monthly figure. For SaaS businesses, a more important decision is determining what customers are actually paying for: the number of users, features, storage capacity, number of transactions, or the outcomes they achieve.
One approach that is increasingly being used is usage-based pricing, which charges based on the level of usage. For example, customers pay based on the number of API calls, documents processed, transcription minutes, automation tasks, or the volume of data used.
This model can help products grow alongside customers. However, if implemented solely because it is popular, customers may struggle to estimate their bills, and internal teams may lose control over margins.
What is usage-based pricing?
In a traditional subscription model, customers pay a fixed fee each month. In a usage-based model, costs change according to consumption. There is also a hybrid model: customers pay a base monthly fee that includes a certain quota, then pay additional fees when they exceed that limit.
Stripe's documentation categorizes usage-based models into several forms, including pay-as-you-go, fixed fees with overage, and credit systems that decrease with usage. These differences are important because the customer experience heavily depends on how these costs are packaged.
For example, "Rp100 per transaction" sounds simple. However, "Rp1,000,000 per month including 10,000 transactions, then Rp150 per subsequent transaction" provides customers with a different level of certainty.
Advantages: revenue can follow value and costs
The main advantage of this model is the clearer relationship between usage and revenue. If customers use the product more as their business grows, the service provider's revenue also increases without always requiring a new sales process.
This model is also suitable for products with variable operational costs. AI processing services, hosting, messaging, cloud infrastructure, and APIs typically require different resources based on usage. Charging all customers a fixed price can make heavy users unprofitable.
From the customer's perspective, usage-based rates can feel fairer for small businesses. They do not need to purchase a large package upfront before knowing if the product is truly useful.
Analysis: This fairness only feels valid if the billed units are easy to understand and genuinely relate to value. Customers do not always care how many internal processes occur on the server. They are more likely to accept costs based on "documents successfully processed" rather than on technical metrics that are difficult to translate into business benefits.
Biggest risk: unpredictable bills
Problems arise when usage is unstable. A marketing team might send out a large campaign in one week. A development team could experience a spike in API calls due to misconfiguration. AI users may incur high costs simply because one workflow reads context too long.
For customers, a sudden spike in bills without warning feels like a penalty. For product providers, this situation can trigger complaints, refund requests, or even subscription cancellations.
Therefore, usage-based pricing needs to be equipped with several safeguards:
- A dashboard that shows usage in near real-time.
- Alerts when usage reaches a certain percentage of the quota.
- Spending limits or usage caps that customers can set.
- Bill estimates before the end of the period.
- Clear notes on what counts as one unit of usage.
Transparency is not an added feature. In this model, transparency is part of the product.
Choose value metrics, not the easiest metrics to calculate
A common mistake is choosing metrics because they are easy for the system to measure. The number of tokens, gigabytes, or requests may be easy to track, but they are not necessarily easy for customers to understand.
Use the following questions to test pricing metrics:
- Can customers estimate their usage before purchasing?
- Does higher usage typically mean higher business value?
- Can customers control that usage?
- Does this metric still make sense as the product evolves?
- Is the cost of measuring and billing it worth the revenue?
For example, an automation tool may be easier to sell with pricing based on the number of workflows executed rather than the number of internal operations occurring in each workflow. Customers buy the results of automation, not the technical details behind it.
When is this model suitable?
Usage-based pricing usually makes more sense if three conditions are met. First, the higher the usage, the greater the value received by the customer. Second, the service provider's costs also increase significantly as usage rises. Third, customers can monitor and control consumption.
This model is suitable for APIs, infrastructure, document processing, messaging, data services, and tools that are indeed used unevenly from month to month.
Conversely, this model can be a poor choice if customers need a fixed budget, usage is hard to predict, or the product's value comes more from access to features than from usage volume. For project management applications, for instance, charging per task may feel confusing if customers are actually buying team coordination and visibility of work.
Start with a hybrid model
For many products, a hybrid model is safer than immediately implementing pure pay-as-you-go. A base fee provides customers with certainty, while the usage component helps businesses capture value from heavy users.
The structure can be simple:
- Starter Package with a fixed fee and a small quota.
- Growth Package with a larger quota, usage reports, and lower additional rates.
- Enterprise Package with a minimum commitment, usage limits, and negotiated pricing.
This approach also allows for learning. Teams can observe actual consumption patterns before setting permanent rates.
What you can do now
If you are developing a digital product, do not start with the question "what is the competitor's price?" Start by mapping costs and value.
- Document the main activities performed by customers.
- Identify activities that are closest to business outcomes.
- Measure internal costs for each of those activities.
- Test two or three pricing structures with potential users.
- Simulate light, normal, and extreme usage scenarios.
- Add notifications and cost limits from the first version.
Consider the initial price as a hypothesis, not an unchangeable decision. What needs to be maintained is clarity for customers and the health of unit economics—the relationship between revenue from one customer and the cost to serve them.
A good price is not the most sophisticated one, but one that makes customers feel their costs are reasonable and keeps your business sustainable.
Usage-based pricing indeed offers exciting monetization opportunities, especially for products with variable consumption and costs. However, its success is not determined by the label "pay-as-you-go." The determining factors are relevant metrics, reasonable cost predictions, and a customer experience that does not make them afraid to use the product.
Sources & further reading
- Recurring pricing models - Stripe Documentation
- Pay-as-you-go and usage-based pricing examples - Stripe
- AI Pricing Models Explained - Stripe
– Rio Yotto @rioyotto