SaaS Pricing Models: 9 Options and How to Choose

The right SaaS pricing model is the one where your price grows with the value your customer gets, and that you can explain in one sentence. Most SaaS products use one of nine pricing models, or a mix of them, ranging from a single flat monthly price to per seat, per location and pure usage-based billing. Pick the one that tracks what your customers already measure in their own business.

This post is about pricing your own product, not the cost of building it. If that's what you need, start with my breakdown of what it costs to build a SaaS in Europe. I'm a developer, so for each model I'll also cover what it means for your code and billing setup.

The short answer

The key idea in SaaS pricing is the value metric: the unit your price follows, such as seats, locations or transactions. The table shows all nine models, what the customer pays for and how much work each one takes to build.

My rule of thumb: start with a flat price or two to three tiers. The exception is when your own costs rise directly with customer usage, for example SMS, payment processing or AI calls. Then usage belongs in the price from day one. Pricing is one of several early decisions, and my step-by-step guide to building a SaaS covers the rest, from idea to paying customers.

Simple models: one price or a few plans

These two are the easiest to explain, sell and build.

1. Flat-rate pricing

One price gets you the whole product, for example €29 a month or €290 a year. There are no plans to compare, so customers know exactly what they will pay.

It works when your customers are similar and get roughly the same value. The trouble starts when they don't. Small customers find it too expensive, large ones pay too little, and you have no built-in way to earn more as customers grow.

Technically, this is as simple as it gets. One subscription in Stripe or Paddle covers it, and your first customers can pay through a payment link.

2. Tiered pricing

Two to four levels, usually called something like Starter, Pro and Business, each with more features or higher limits. It's one of the most common models in B2B SaaS because small and large customers can pay different amounts while the pricing page stays readable.

The usual mistake is too many tiers, split on things buyers don't care about. I recommend three tiers at most, separated by one or two things customers actually notice, such as the number of projects or access to integrations.

In code, the app needs to know what each tier includes. Keep limits and entitlements in the database or in one central config instead of checking plan names all over the codebase. Otherwise every price change turns into a development task.

Models that grow with the customer

The next three let your revenue rise as customers get bigger. The difference is what you count.

3. Per-seat pricing

Customers pay for each user with a login, usually per month. It's the default for collaboration tools. Intercom, for example, currently charges between $29 and $132 per seat per month depending on the plan, according to its pricing page.

It fits when every user gets value and headcount tracks the size of the customer.

The downside is that you penalize customers for rolling the product out internally. People start sharing logins, and products where only one or two people do the work end up cheap no matter how heavily they're used.

Under the hood, you need to count seats, handle invitations and prorate when someone is added mid-cycle. Stripe and Paddle support quantities on a subscription, but your code is what keeps that number in sync.

4. Per active user

Customers only pay for users who actually used the product during the billing period. Slack is the well-known example: under its fair billing policy, a member counts as inactive after 28 days without use, and the account gets a prorated credit for the rest of the period.

It fits when usage swings, for example with seasonal staff or temps, and when customers hold back on inviting colleagues because they fear the bill.

The catch is that revenue becomes harder to predict for both sides, and "active" needs a precise definition. Does a login count, or does the user have to do something? You'll need activity tracking per user, a calculation per period, and credits or invoice adjustments. It's clearly more work than plain per-seat billing.

5. Per location or per unit

Customers pay per physical unit: shop, clinic, warehouse, vehicle, machine or rental property. A booking system for physiotherapy clinics might charge €60 per clinic per month regardless of how many therapists work there. A fleet tool might charge per vehicle.

It fits when value follows physical units and customers already think in them. The owner of four shops knows exactly how many shops she has, but probably not how many user accounts she needs. Staff sharing one screen at the front desk stops being a problem.

The weakness is that a small location pays the same as a large one. Size bands fix most of that, for example up to five practitioners and more than five. Also define what counts as a location before someone asks whether the pop-up store is included.

This model is easy to build if locations exist in your data model from the start, so one customer account can have several locations, each with its own users and data. Adding it later means a bigger rebuild. I cover those choices in my post on multi-tenant SaaS architecture.

Models that follow usage

The last four tie price to what customers consume or achieve. They sit closest to your own costs, but they're also the hardest to build.

6. Usage-based pricing

Customers pay for what they use: transactions, messages sent, gigabytes or API calls. Stripe is a clear example. There's no monthly fee, just a charge per payment: 1.5% plus €0.25 for standard EEA cards, according to Stripe's pricing page for Ireland.

It fits when your own costs follow usage and customers consume very different amounts. Getting started is easy for the customer because there's no fixed commitment.

The downside is that customers can't predict the bill. Finance teams often want a fixed amount to budget for, and a product where every click costs money can make employees use it less.

Technically, it's the heaviest model. You need to record every event, aggregate usage without double counting, show usage inside the product and send alerts at thresholds. Stripe offers usage-based billing tools, but your code still has to send the numbers, and they have to be right every time.

7. Base fee plus usage

Customers pay a fixed monthly fee that includes a usage quota, then pay extra above it. For example, €49 a month could include 1,000 SMS, with €0.04 for each message above that.

For many B2B products with real variable costs, this is the best compromise. Customers get a predictable budget in a normal month, and you're covered if one account suddenly uses ten times more than expected.

The risk is surprise invoices. Warn customers when they reach, say, 80% of their quota so the overage doesn't come as a shock. On the build side, you need the same metering as pure usage-based pricing plus quotas that reset each period and customer notifications.

8. Credit-based pricing

Customers buy a pool of credits upfront, and different actions spend different amounts. It has become common in AI products. Lovable, for example, prices its plans by the credits they include rather than by seats, and a simple task costs fewer credits than a complex one, according to Lovable's pricing page.

Credits fit when every action costs you money and that cost varies, as with calls to AI models. You get paid before you incur the cost, and you can change what an action costs without touching the headline price.

The downside is that customers struggle to know what a credit is worth, and expiring credits can feel like a trap. Technically you're building a small ledger: a balance per customer, a log of every movement, a price per action, expiry rules and top-up purchases. It has to reconcile to the cent.

9. Outcome-based pricing

Customers pay for a measurable result, such as a resolved support ticket, a booked meeting or a completed order. Intercom's Fin AI agent costs $0.99 per outcome, and Intercom spells out exactly what counts as one, such as a customer confirming their issue is resolved.

It fits when the result can be measured without argument and the customer would otherwise hesitate to pay for something new and unproven. It's an easy sell because customers only pay when it works.

On the other hand, disputes about what counts as a result will happen, and your revenue depends on factors you don't control. The definition has to be encoded precisely, every outcome recorded, and every charge traceable if a customer asks. It's rarely the right choice for a first version.

Freemium and free trials aren't pricing models

Freemium and free trials often get listed alongside pricing models, but they're about how customers get in, not what they pay for. You can combine either one with any of the nine models. A free tier with capped usage is freemium on top of tiered pricing, and 14 days of free access is a trial on top of a flat rate.

The choice has a big effect on revenue and support load, so I've covered it separately in freemium vs free trial vs paying from day one.

How to choose a pricing model

Choosing a model is a business decision. Work through these six steps before anything gets built:

1. Find your value metric. Ask five customers or prospects what grows in their business when your product helps more: people, locations, orders or cases. That number is your best candidate to carry the price.
2. Run the numbers on your variable costs. If each customer action costs you money, such as SMS, AI calls or storage, your price has to follow usage. Otherwise one big customer can cost you more than it pays.
3. Think about who approves the invoice. Mid-sized companies with a procurement process usually want a fixed amount to sign off. Pure usage-based pricing can stall a deal that was otherwise done.
4. Choose the simplest model that covers steps 1-3. Test it by writing your pricing in a single line. If you can't, it's too complicated for a first version.
5. Sell before you build. Your first customers can pay through a payment link or a manual invoice while you learn what they'll pay for. Multiple plans and coupon codes are on my list of features your MVP can skip at launch.
6. Put a review date in the calendar. Your first price is an educated guess. Revisit it after three to six months or once you have 20-30 paying customers, whichever comes first.

Build pricing you can change later

Your first price is almost never your final one. Preparing the code for that costs a little extra now and saves a rebuild later. These are the four things I recommend having in place from the start:

• Plans, limits and entitlements live in the database or one config file, so a price change doesn't require a new release.
• What a customer has access to is separate from how they pay. That way you can switch payment provider or give one customer a custom deal without changing the product.
• The data model supports several price versions at once, so existing customers can be grandfathered on their old price when you raise it for new ones.
• Usage is tracked from day one, including usage you don't charge for yet. When you want to change the model, you'll have real data to base it on.

VAT is the final piece. If you sell to customers in other EU countries, it matters whether your payment provider also handles VAT for you or leaves it to you. I compare the options in my post on SaaS subscription billing.

Currency is the other early decision for a European SaaS. Pricing only in EUR keeps things simple, but buyers in the Nordics and the UK may expect SEK, NOK, DKK or GBP. Every extra currency is another price list to maintain, so add them when real customers ask, not before.

Next steps: from pricing model to working billing

Write your pricing in one line and check it against the six steps above. If the answer is a flat rate or two to three tiers, an off-the-shelf billing provider and very little code will get you going. If the model needs locations, metering or credits, plan for it from the start, because it shapes your data model.

Before larger builds, I run a paid, fixed-price discovery phase where you and I work out, among other things, how pricing should work inside the product. You can see how a project runs on my SaaS development page.

Frequently asked questions

How do I find the right price point for my SaaS?+

Start from what the product is worth to the customer, not from what it costs you to run. Compare it with their current alternative: hours of manual work, a spreadsheet or a competitor. Ask prospects directly what the problem costs them today. If you're unsure, err on the high side. Offering a discount is much easier than raising prices on customers who already pay.

Should I offer a discount for annual billing?+

Usually, yes. I typically suggest a discount worth one to two free months. You get cash upfront, and a customer who has paid for a full year has one less reason to cancel halfway through. If you offer both monthly and annual billing, make sure your billing setup can handle switching between them mid-cycle, including prorated charges.

Should SaaS prices include VAT?+

If you only sell to businesses, showing prices excluding VAT is standard, as long as you say so clearly. If you sell to consumers in the EU, the price they see generally has to be the final price including VAT. With both types of customer, you can show both or let visitors choose. VAT and price display rules across EU countries get detailed, so confirm your setup with an accountant.

Can I combine pricing models?+

Yes. Intercom, for instance, combines per-seat pricing with a charge per AI outcome, and tiers with a per-user component are common. Every extra dimension makes your pricing harder for customers to understand and harder for you to build and support, though. Start with one value metric and add a second only when customers show they need it.

How do I change my pricing model once I have customers?+

Roll the new model out to new customers first, so you can measure the effect without putting existing revenue at risk. Give current customers plenty of notice and a clear reason, and consider grandfathering them on the old price for a period. Check your terms of service for the notice period you've committed to before you change anything.