SaaS pricing models: types, examples and how to choose

A SaaS pricing model is the rule that turns what a customer gets into what they pay. It decides whether a customer pays a fixed amount, pays for each user, pays more as they use more, or pays for a bundle of features. It also decides who is happy with the price: your smallest customers, your biggest ones, or neither.

Most guides to SaaS pricing models stop at a list: seven or ten models, each with a pro and a con. The hard part is choosing between them, and then discovering what your choice does to your invoices, your forecasts, your support queue and your renewals. This guide is built around those questions.

You will find the seven main models explained in plain terms, then a worked example that puts one fictional product through five pricing structures at three customer sizes, so you can see how the bills diverge. After that comes a scorecard to choose between models, a closer look at hybrid and enterprise pricing, a checklist of what each model asks of your billing system, a playbook for changing prices without losing customers, and an honest note on which benchmark statistics you can trust.

Every statistic or rule here names where it comes from, and where the common advice online has no traceable source, we say so.

What is a SaaS pricing model?

A pricing model answers three questions:

1. What do you charge for? The thing the price is attached to: users, usage, features, a bundle or an outcome. This is called the value metric.

2. How does the price change as the customer grows? Does it stay flat, rise per unit, step up in bands, or fall per unit as volume rises?

3. How often and when do you collect it? Monthly or annually, in advance or in arrears.

The first two questions are the pricing model. The third is the billing model, and it deserves its own treatment: see our guide to SaaS revenue models and billing models. Pricing strategy is a separate, earlier question again: how much to charge. If you are still working that out, start with the SaaS pricing strategy guide.

Keeping the layers apart matters because they fail in different ways. A pricing model can be right and a billing model wrong, and the symptom (disputed invoices, failed renewals, a forecast nobody trusts) looks the same from the outside.

The seven main SaaS pricing models

1. Flat-rate pricing

One price, one product, everything included. For example, $199 a month for the whole product. It is simple to explain, simple to bill and free of surprises. The cost is that a customer using the product lightly and a customer using it heavily pay the same, so the price captures no extra value from your biggest customers.

Suits: simple products with a narrow customer profile, or early-stage products where learning matters more than optimising revenue.

Watch for: heavy users who cost you more to serve than they pay.

2. Per-user (per-seat) pricing

You charge for each person who uses the product, for example $15 per user per month. It is predictable, grows with the size of the customer and is easy to forecast. Stripe’s documentation lists per-seat pricing as one of the standard recurring pricing structures, alongside flat rate, tiered and usage-based.

Suits: collaboration tools where each extra person gets clear value.

Watch for: customers rationing seats to save money, which can slow adoption, and a price that drifts away from value when the value does not depend on headcount.

3. Tiered pricing

The word covers three different things: packages at fixed prices (good, better, best), volume pricing, and graduated pricing. Stripe’s documentation distinguishes volume-based tiering, where the quantity bought sets the price, from graduated tiering, where usage is priced band by band. We explain all three, with the arithmetic, in Tiered pricing explained.

Suits: products with clearly different customer segments, or usage that scales widely.

Watch for: too many tiers, and boundaries that create price cliffs.

4. Usage-based (metered) pricing

You charge for what the customer consumes: messages sent, records stored, transactions processed. The price rises as usage rises, which aligns cost with value and lowers the barrier to starting. Stripe’s documentation describes three common variants: a fixed fee plus overage, pay-as-you-go, and credit burndown, where a customer buys a balance and draws it down.

Suits: products where value clearly tracks consumption.

Watch for: bill shock and forecast volatility. Usage-based billing also needs a metering step, so accurate measurement becomes part of the product. Read more about usage-based billing.

5. Per-feature pricing

A base product plus paid add-ons. Customers pay only for what they need and you get a natural upsell path.

Suits: products where needs differ widely and features can be separated cleanly.

Watch for: complexity. Many add-ons make the pricing page hard to read and the product hard to sell.

6. Freemium

A free plan with no time limit, with paid plans for more. It lowers the cost of acquiring users and lets the product sell itself. It is not a pricing model on its own but sits on top of one of the others, and the paid structure underneath still has to work.

Suits: products that are cheap to serve and spread through use.

Watch for: free users that cost money to serve and support, and conversion that is too weak to pay for them. Be wary of any article that quotes a specific freemium conversion rate without a source; we found several, and none could be traced.

7. Hybrid pricing

A mix of the above: a platform fee plus usage, a subscription with overage, seats plus usage, or a prepaid balance drawn down by usage. Hybrid is where many products end up, because it gives predictable base revenue and still grows with usage. We cover its parts in detail below.

The seven models compared

A worked example: one product, five pricing structures

Lists of pros and cons hide the thing that matters most: how different the bills actually are. So here is one fictional product, priced five ways, for three customer sizes. All figures are illustrative, not benchmarks or recommendations.

The product: an analytics tool. The customers:

• Small: 3 users, 20,000 events a month

• Medium: 25 users, 400,000 events a month

• Large: 200 users, 6,000,000 events a month

The five structures:

• Flat: $199 a month for everyone.

• Per-seat: $15 per user per month.

• Graduated usage: $2 per 1,000 events for the first 100,000, $1.50 per 1,000 for the next 900,000, and $1 per 1,000 beyond 1,000,000. Each band applies only to the events inside it.

• Volume usage: the same bands, but the whole quantity is charged at the rate of the band it reaches.

• Hybrid: a $99 platform fee including 100,000 events, plus $5 per user, plus $1 per 1,000 events above 100,000.

How the numbers work. For the medium customer under graduated pricing: 100,000 events at $2 per 1,000 is $200, and the next 300,000 at $1.50 per 1,000 is $450, so $650. Under volume pricing the same 400,000 events all fall in the second band, so $1.50 x 400 is $600. For the large customer under hybrid: $99 platform fee, plus 200 users at $5 which is $1,000, plus 5,900,000 events above the allowance at $1 per 1,000 which is $5,900, so $6,999.

What the example shows.

• Flat pricing hides the spread. The large customer pays the same $199 as the small one, although it uses 300 times the events. If serving that customer costs more, flat pricing is a subsidy.

• Spread varies by structure. The large customer’s bill is about 67 times the small customer’s under per-seat pricing, about 150 times under volume usage, about 164 times under graduated usage and about 61 times under hybrid. The structure you choose decides how much of a customer’s growth you capture.

• Volume and graduated differ at scale. At 6,000,000 events the volume bill is $550 lower than the graduated bill. Customers will notice, and so will your finance team.

• Volume pricing has a cliff. At exactly 1,000,000 events the volume bill is $1,500. At 1,001,000 it is $1,001, because the whole quantity drops to the lower rate. The customer pays $499 less for using more. Graduated pricing never does that.

• Hybrid is the most predictable at the bottom. The small customer pays a stable $114 whatever its usage does, up to the allowance.

Run your own version of this table before you choose. It takes an afternoon with a spreadsheet and your real customer data, and it will show you which structure rewards you for the customers you want.

How to choose a SaaS pricing model: a scorecard

Work through these questions with your own numbers. Each answer points toward certain models.

Two rules of thumb. First, start with the simplest model that matches your value metric, and add complexity only when customers force it. Second, if you cannot explain how a customer’s bill was calculated in two sentences, the model is too complicated for your support team to defend.

Hybrid pricing, step by step

Hybrid is a combination of up to five components.

• Platform or base fee. A fixed amount per period. It makes revenue predictable and covers the cost of having a customer at all. In the combined models on Google Cloud Marketplace, the documentation does not allow the base fee to be zero.

• Included allowance. The usage covered by the base fee. It lets customers start without worrying about a meter.

• Overage. What the customer pays for usage beyond the allowance, either per unit or in bands.

• Commitment. A minimum spend or volume agreed in advance, usually in exchange for a lower rate.

• Credits and drawdown. A prepaid balance that usage draws down. The customer controls spend; you collect cash early.

Not every hybrid has every component. A typical self-serve hybrid is base fee plus included allowance plus overage. A typical enterprise hybrid adds commitment and credits. AWS Marketplace’s contract-plus-pay-as-you-go model is a real example of the second kind: the customer buys a quantity up front under a contract and any usage beyond it is billed pay-as-you-go.

On evidence: the Maxio 2025 Pricing Trends Report found that companies using a hybrid of subscription and usage pricing had the highest median growth, 21%. Treat that as correlation, not proof. Maxio sells billing software, the report’s methodology is not fully described, and the follow-up article cites a sample of 316 companies. It is a useful signal that hybrid is common among growing companies. It does not show that hybrid pricing causes growth.

Enterprise SaaS pricing models

Enterprise deals rarely use a public price list. They are structured as contracts, and the details matter more than the label. The marketplace documentation from AWS and Google gives a verified view of how those contracts are built.

• Contract length. On AWS Marketplace, contract terms run in lengths such as 1, 12, 24 or 36 months, and private offers can extend much longer, up to 144 months.

• Quantity up front. In a contract model the customer buys a quantity of whatever the price is attached to, for example users or units, for the term.

• Overage. Usage above the contracted quantity can be billed on a pay-as-you-go basis alongside the contract.

• Mid-term changes. In AWS’s model a customer can upgrade mid-term, with a prorated credit, but cannot reduce the contract until renewal.

• Custom pricing. Both marketplaces provide private or custom offers as the route for negotiated pricing.

These are marketplace rules, so they will not match every direct deal. But they describe a structure that most enterprise contracts echo: a term, a commitment, a way to pay for more, and no easy way to pay for less mid-term. Stripe’s own documentation treats commitments, ramp schedules and prepaid credits as needing contract-aware billing beyond basic usage meters.

What we could not verify, and so will not claim: that enterprise pricing is usually value-based, how common “contact sales” pricing is, or typical negotiated discount ranges. Be sceptical of any page that states these as facts without a source.

For your own enterprise offering, decide these things in advance, so each deal is a variation and not a new invention:

1. Standard contract lengths and what changes the rate.

2. What a customer can add mid-term, and how it is charged.

3. What happens at renewal: price increases, minimum commitments and notice.

4. How usage above the commitment is priced.

5. Which currencies, tax treatments and invoicing terms you can support.

What each model asks of your billing system

Your pricing model is a promise. Your billing system has to keep it on the thousandth invoice as well as the first. Use this checklist to see what you are signing up to.

Beyond the table, every model also asks for:

• Currencies and local tax that work in each market you sell in.

• Clear invoices that show what the customer paid for and why, so that support can answer questions from the same document the customer sees.

• Failed payment recovery. A renewal that fails is a cancellation nobody chose. See how dunning management works.

• Launching new plans without a development project. If every pricing change needs engineering time, you will change prices too rarely.

OpenByte bills subscriptions, usage-based and prepaid models, in advance or in arrears, in any currency, with local tax built in. It checks every charge against the customer’s plan, history and payments before it goes out. See the Billing page, or read more about recurring billing software.

How to change your pricing model without losing customers

Changing a pricing model is harder than choosing one, because customers hold expectations about what they pay. A migration playbook:

1. Decide who is affected. All customers, new customers only, or customers at renewal. New customers only is the lowest risk. Existing customers move at their next renewal date.

2. Decide on grandfathering. Keep existing customers on their old terms for a fixed period or indefinitely. Both choices cost something: indefinite grandfathering means supporting two systems.

3. Model the winners and losers. Run every existing customer through the new structure. Anyone whose bill rises sharply needs a conversation before the change.

4. Give notice. Marketplace platforms set their own minimum notice periods for price increases, and the Google Cloud documentation specifies a waiting period before a change can take effect. Even where no rule applies, customers need time to budget.

5. Test with a cohort. Introduce the structure to new sign-ups first and watch conversion, early churn and support volume.

6. Check billing before launch. Confirm that every plan change, proration, credit and threshold works as the new price page describes.

7. Watch after launch. Look at churn, downgrades, failed payments and support tickets for the first renewal cycle.

Why pricing models fail: five mechanisms

• Bill shock. Usage-based bills that vary unpredictably produce tickets, disputes and chargebacks. Mechanism: the customer cannot predict the bill, so they find out at the end of the month. Fix: allowances, caps, alerts and clear invoices.

• A metric that does not track value. If the thing you charge for grows without the customer getting more value, they will resist. Mechanism: the price and the benefit move apart. Fix: choose the metric with customers.

• Forecast volatility. Usage revenue moves with customer activity. Mechanism: variable revenue is harder to project. Maxio found that 73% of usage-based companies actively forecast variable revenue, which suggests it is treated as a discipline, not a given. Fix: a fixed base, commitments and good measurement.

• Tier clutter. Too many plans make the price page unreadable and every change a project. Mechanism: each plan multiplies the cases billing and support must handle. Fix: fewer plans and clear differences.

• Quiet billing errors. A model nobody can bill accurately produces duplicate charges, wrong proration and missed revenue. Mechanism: complexity outruns the billing system. Fix: test every rule before launch and check charges before they go out.

What the benchmarks can and cannot tell you

Pricing advice is full of statistics, and most are weaker than they look. Here is how we treated them.

• We used statistics with a traceable source and an honest caveat, such as Maxio’s 2025 report with its sample size and its vendor interest stated.

• We did not use freemium conversion rates, typical churn bands and “three tiers convert best” claims that appear across vendor blogs with no source. We found several, and none could be traced.

• We did not use figures that are repeated second-hand, such as the share of companies using hybrid pricing, until the primary report has been checked.

A good rule: if a statistic comes from a company that sells the thing it is measuring, read the methodology before you repeat it. If there is no methodology, do not repeat it.

Glossary

• Value metric: the unit the price is attached to, such as seats, events or records.

• Meter: the measurement of usage that billing uses to price a period.

• Allowance: usage included in a base fee.

• Overage: usage beyond an allowance or commitment, billed on top.

• Commitment (commit): a minimum spend or volume agreed in advance.

• Ramp schedule: a commitment that increases over the contract term.

• Credit burndown: a prepaid balance drawn down by usage.

• Graduated pricing: each unit is priced at the band it falls in.

• Volume pricing: the whole quantity is priced at the band it reaches.

• Proration: charging for part of a period when a customer changes plan or seats mid-cycle.

• Grandfathering: keeping existing customers on their old price.

• True-up: a later charge that corrects a bill for changes since it was issued.

Frequently asked questions

What is the most common SaaS pricing model?

We could not find a reliable source that ranks them, and we would be wary of any that claims to. Per-seat, tiered and subscription structures are widely used, and hybrid is common among growing companies, but how common is not something we can state from verified data.

Which SaaS pricing model is best?

None is best in general. The right model matches your value metric, your buyers’ need for predictable bills and what you can bill accurately. Use the scorecard above with your own customer data.

What is the difference between a pricing model and a billing model?

A pricing model is what you charge for and how the price scales. A billing model is when and how you collect it. You can change one without the other. See SaaS revenue models and billing models.

What is hybrid pricing?

A combination of structures, most often a fixed platform fee with an included allowance and overage, sometimes with commitments and prepaid credits. It gives predictable base revenue and still grows with usage.

Is usage-based pricing predictable?

Not for the customer or for you, unless you add structure. Allowances, caps, commitments and clear invoices make usage-based pricing easier to live with.

What is the difference between graduated and volume pricing?

Under graduated pricing each unit is charged at the rate of the band it falls in. Under volume pricing the whole quantity is charged at the rate of the band it reaches. The worked example above shows a $550 difference at 6,000,000 events. See Tiered pricing explained.

How do enterprise SaaS pricing models differ?

They are structured as contracts: a term, a committed quantity or spend, a way to pay for more, and usually limits on reducing the commitment mid-term. The AWS and Google Cloud marketplace documentation shows the structure in detail.

How do I change my pricing without losing customers?

Decide who is affected, model the winners and losers, give notice, test with a cohort and confirm your billing handles every case before launch. The playbook above sets out the steps.

Key takeaways

• A pricing model is the rule that turns what a customer gets into what they pay. The same product can produce very different bills under five different structures.

• Choose with the scorecard, not with the most popular model. Your value metric, customer sizes and how predictable usage is matter more than what competitors do.

• Hybrid pricing, a base fee plus usage, is common because it balances predictable revenue for you with fairness for the customer.

• Every model asks something of your billing system. Check that yours can do it before you commit.

• Change models carefully: grandfather existing customers, migrate in stages, and tell people early.

Pricing is rarely right first time. Pick the model that fits your customers today, write down why, and revisit it when something changes. Take the scorecard and the migration checklist back to your team and argue with them. The numbers in our worked examples are invented to show the arithmetic, so run your own before you decide. And if you’d like to talk it through with people who live in billing every day, we’re easy to find.