You are about to price a product, or you priced it a while ago and something has started to feel wrong. Each unit of use costs you money, through a third-party API, compute or storage, and some customers use far more than others. So you are weighing a fixed monthly fee in a few tiers against charging for what customers use. Or you have already added a usage charge on top of a subscription and are finding out how much more there is to run: usage to collect, allowances to reset, overage to handle, invoices to time, and customers asking how much they have used.
The opposite also happens. A product that charges for use hears from customers that the bill is too hard to predict, and they ask for a fixed price.
This post does not say which model is better. It sets out what each one is good at and who carries its cost, a few questions that point one way or the other, and the work a mix of the two adds. Where it describes how billing behaves, it uses Stripe as the example, because many teams in this situation bill through it.
What a fixed subscription is good at
A subscription charges the same amount every period for a plan. The buyer knows in advance what they will pay, which is what a budget or a purchase approval needs, and you know roughly what next month's revenue will be.
The cost lands in two places. Light and heavy users pay the same, so the light ones subsidize the heavy ones. And if every unit of use costs you something, the margin on a plan shrinks as a customer's usage grows. One founder described pricing a subscription well above similar apps and still nearly being sunk by a small number of heavy users; they moved to a base subscription that included some usage and charged for usage beyond it. In a different thread, a developer whose inference costs had grown faster than revenue was advised to show users their usage first, keep light users on the old price, and raise the price for the heaviest ones.
What usage-based pricing is good at
Usage-based pricing charges for what a customer actually uses. The price follows your cost, or the value the customer gets, and a small customer can start without committing to a plan.
The cost moves to the buyer: they do not know in advance what they will pay. That is part of the model's structure rather than a flaw in any one product, and it shows up in different ways. One founder who started with usage pricing and later added fixed tiers found that the fixed tiers sold far better, because the bill was predictable, and that some institutional customers could not approve a variable price at all. Another, who had charged per use, found that customers held back, and usage picked up after a move to an unlimited subscription.
On your side, usage pricing means recording every billable event, counting it into the right period and reconciling the total with what you invoice, and revenue moves with your customers' activity. When the usage bill doesn't match usage follows where that counting goes wrong.
Questions that decide it
- Does each unit cost you something you can't ignore? If a heavy customer costs you many times what a light one does, a flat price puts your margin in the hands of your heaviest users. If extra use costs you close to nothing, a subscription gives up little.
- How far apart are your customers' usage levels? When most customers use about the same amount, a few tiers fit them. When usage spreads across a wide range, tiers either undercharge the top or price out the bottom.
- Does the buyer need to know the amount in advance? A buyer who pays from a fixed budget, or has to get a purchase approved, needs a number before they start. A buyer whose usage comes and goes may prefer to pay for what they use. One developer wrote that this is what he wants as a buyer, while noting that larger companies tend to want a predictable fee.
- Can the customer see their usage before the bill arrives? When customers cannot see what they have used so far, the first total they see is on the bill. If you can't show it yet, that is a reason to cap usage or to start with a subscription.
None of these settles it alone. Together they tell you which side the uncertainty should sit on, and how much work it takes to keep it there.
What public switches looked like
Companies have moved in both directions and said why.
- In a post in July 2025, Cursor explained why it had changed its Pro plan from a number of requests a month to an amount of included usage: newer models used far more tokens on long tasks, and the hardest requests could cost an order of magnitude more than simple ones, so a price per request no longer matched its cost. The same post said the change had not been communicated clearly and had surprised many users. Cursor refunded unexpected charges from the previous three weeks and said it would give notice before future pricing changes and improve how usage is shown.
- In February 2025, MongoDB announced a Flex tier for its Atlas database service that replaced its shared tiers and its usage-priced serverless tier: a base fee plus usage-based charges, capped each month. It said the cap was there to keep costs from running away, a problem it described as persistent with serverless architectures, and pointed customers who need more to dedicated clusters.
- In October 2024, Fly.io announced on its community forum that it was dropping plans and would charge for what customers use, with unit prices unchanged. Support and compliance that had been bundled into plans became separate purchases, and customers already on a plan were not affected. It gave two reasons: it wanted pricing to be as simple as possible, and users found it hard to understand what a plan included.
No direction wins across the three. Two moved toward paying for use and one toward a predictable ceiling, and each had to decide what happened to customers already paying under the old model.
The pressure can also come from customers. One seller who had moved from per-seat to usage pricing wrote that, as customers' usage builds up over the years, they start asking to go back to per-seat, so that their cost has a ceiling.
What mixing them adds
A common middle ground is a subscription that includes an allowance, with usage beyond it charged as overage. Stripe's documentation describes this model as combining predictable billing with room to scale: customers pay a fixed fee for a base package, and heavy users pay for what they use beyond it.
It also adds things to manage that a plain subscription does not have:
- Collecting usage without losing or doubling it. Every billable event needs an ID that survives retries, and somewhere that catches duplicates.
- Resetting the allowance each period. Someone has to decide when a period starts, and whether unused allowance carries over or is lost at the end of it.
- What happens past the allowance. Block, charge, prompt an upgrade or stop at a ceiling; each moves the cost onto someone. When a customer runs out of quota goes through the four.
- Which invoice the usage lands on. Stripe's documentation on subscriptions with several prices states that a fixed price is charged at the start of each period, for the period ahead, while usage is charged at the end of the period in which it happened. When one subscription has both, each renewal invoice carries the previous period's usage together with the new period's fixed fee, and all prices on one subscription must be in the same currency. Its example of a flat fee with overages shows a customer's second invoice containing last month's usage fees and next month's base fee. Customers who expect one fee a month will ask about that invoice, so the line items and the email that goes with it need to say which period each part covers.
- Whether the customer sees usage before the invoice. Stripe's documentation on credit-based pricing states that its basic usage-based billing reconciles usage at invoice time, so neither the customer nor your team can see a live balance or usage total in the middle of a cycle, and that prepaid credits are applied when the invoice is created, so a customer can use more than their balance within a period. The same page recommends another of Stripe's usage-based billing products for new integrations. Its documentation also notes that usage events are processed asynchronously, so preview invoices and usage summaries may lag behind what was just sent. If customers need to watch their usage as it happens, that view has to come from somewhere, and its numbers have to agree with the invoice.
- Usage at the edges of a subscription. Stripe's documentation states that usage recorded during a trial is not billed, that usage reported while a subscription is paused is not invoiced and the first invoice after resuming covers events from the resume date on, and that if you cancel without prorating, usage recorded in the current period is discarded. Each of these decides who pays for that usage, through a setting if nobody decides on purpose.
Each item needs an owner and a decision. Whether that is worth it for your product comes back to the questions above.
Two other mixes appear in the public examples. A base fee with a monthly cap gives the buyer a ceiling while you carry the cost above it, so it needs a way up for customers who outgrow it, as with MongoDB's pointer to dedicated clusters. Selling both side by side, usage pricing for those who don't want a monthly fee and fixed plans for those who want a predictable one, lets the buyer choose, at the cost of running two pricing models and two billing paths. The developer who prefers usage pricing as a buyer wrote that, as a seller, he plans to offer both for that reason.
Switching later
Whichever you choose, changing it later is a change for every existing customer at once. Each of them has to land somewhere: kept on the old terms, moved with notice, or moved at renewal. Changing a plan's price when customers are already on it covers those choices, and Adding pricing tiers after launch covers what has to change in your plans and your code. The public examples above show both ends: one company left existing plan holders where they were, and another refunded charges its customers had not expected.
Choosing
Choose by your cost structure and by how your buyers budget. If units cost you little and buyers need a fixed number, a subscription fits. If units cost you a lot and usage varies widely, usage pricing or a mix fits better, and the buyer's need for a predictable bill becomes something you answer with a cap, an allowance or a view of their usage.
If you mix the two, write down before launch: when a period starts and what resets; what happens at the allowance; which invoice each part lands on and how the invoice explains it; what the customer can see before the invoice; and what happens to usage at a trial, a pause and a cancellation. For the first of these, our use case Monthly usage limit walks through giving each plan a monthly allowance that starts again every period.
This post was written by the team building ShipRev, which keeps a SaaS product's identity, subscriptions, metering and entitlements on one customer record. Using ShipRev does not settle any item on that list for you, and not every one of them can be handled in ShipRev. ShipRev is not open yet: the managed cloud is built but not yet open, and the source repository is not public.
Related use case: Monthly allowances