SaaS pricing models fall into seven main types: flat rate, tiered, per seat, usage-based, freemium, hybrid and per feature. The right one is the model where the price rises with the value a customer gets, and where your team can meter, bill and enforce limits without building a second product. For most early-stage B2B tools, that means tiered or per seat.
| Model | Best fit | Build effort | Well-known example |
|---|---|---|---|
| Flat rate | Narrow product, similar customers | Low: one plan, one invoice line | Basecamp |
| Tiered | Mixed customer sizes, clear upgrade steps | Medium: plan limits and entitlement checks | Slack, Basecamp |
| Per seat | Collaboration tools where value grows per user | Medium: seat counting, proration, invites | Atlassian Jira Cloud, Slack |
| Usage-based | APIs, infrastructure, variable workloads | High: metering pipeline, usage reports, alerts | Firebase on its Blaze plan |
| Freemium | Products that spread by use and sharing | Medium to high: free-tier limits, abuse control | Dropbox, Slack |
| Hybrid | Predictable base plus variable consumption | High: subscription plus metered add-ons | Supabase |
| Per feature | Clear add-on modules or premium capabilities | Medium: feature flags tied to billing | Jira Cloud Premium |
The main SaaS pricing models are flat rate, tiered, per seat, usage-based, freemium, hybrid and per feature. Each one picks a different thing to charge for: a single fee, a plan level, a user, a measured unit of use, a free entry point, a mix of these, or access to specific features.
Researchers at Harvard Business School make the same point about platform products: identifying the unit of value becomes essential for profitable selling. In practice that unit is your value metric. Get it right and revenue grows as customers succeed. Get it wrong and customers either feel punished for growing or you leave money on the table.
The list below runs from the simplest to build to the most demanding. For each model we cover when it fits, what it changes in the product build, and a real example. We build SaaS platforms with React, Next.js, Node.js and Supabase, so the build notes come from the plumbing that sits behind a pricing page, not just the page itself.
Flat-rate pricing charges one recurring fee for the whole product. Every customer gets the same features and the same access, whatever their size. It is the easiest model to explain and the easiest to sell, which is why small, focused products often start here.
Flat rate suits a narrow product with a consistent customer profile. If a five-person agency and a fifty-person agency use your tool in broadly the same way, one price removes friction. Basecamp is the textbook case: its published plans are flat monthly prices with no per-user fees, so customers know the cost before they invite their team.
The risk is under- or overcharging. Light users pay more than the value they get, and heavy users pay less than they should. If your costs rise with customer activity, a flat fee can quietly erode margin.
Flat rate is the lightest billing job. You need one product, one price, one subscription state (trialing, active, past due, cancelled) and a clean invoice. There is almost no metering. Most of the effort goes into the payment flow, failed-payment handling and VAT-correct invoices for UK and EU buyers.
Tiered pricing offers two to four plans, each with a different bundle of limits and features, at rising price points. Customers pick the tier that matches their size or needs. It is the most common structure in B2B SaaS because it serves different segments from one product.
Choose tiers when your customers differ clearly in size or sophistication. A solo founder, a ten-person team and a company with security requirements want different things. Slack publishes several paid plans, from a mid-level plan up to an enterprise plan quoted by sales, and Basecamp also steps customers up through plans with different project and storage limits.
The craft is in the gaps between tiers. Each step should have one obvious reason to upgrade, such as more projects, single sign-on or audit logs. Too many tiers and buyers stall; too few and you cannot capture larger accounts.
Tiers create the first real plan-limit logic. You need an entitlements layer: a single place in the code that answers "can this account do this?" based on its plan. We keep that logic server-side in Node.js and read it from the front end, so a limit is never enforced only in the browser.
Plan changes also need rules. Decide up front how upgrades are prorated, whether downgrades take effect immediately or at renewal, and what happens when a customer is over the new tier's limit. These edge cases cause most support tickets.
Per-seat pricing charges for each named user on an account. The bill grows as the customer's team grows, so revenue tracks adoption. It works best where each extra user gets clear, separate value, such as project tools, CRMs and messaging apps.
Seat pricing fits collaboration software. Atlassian's Jira Cloud has been a well-documented example: a MIT knowledge-base note on real SaaS pricing models describes Jira Cloud pricing as metered by user count, with the per-user rate changing by band. Slack's paid plans are also priced per user.
The catch is that seat pricing can discourage the behaviour you want. If adding a colleague costs money, customers share logins or leave people out, which weakens your product's network effect. Seat pricing also fits poorly where one automated workflow delivers all the value.
You must count seats reliably. That means an invitation flow, a rule for deactivated users, role types (full seat, viewer, guest) and a decision on when a seat starts to be billed. Add proration for mid-cycle changes and a clear billing admin screen.
Seat pricing also pushes you to build team and role management early, which is useful anyway. If your product will end up with organisations, workspaces and permissions, we would model them from the first migration rather than bolt them on later.
Usage-based pricing charges for what a customer actually consumes: API calls, messages sent, gigabytes stored, minutes processed. The bill rises and falls with activity. It is the fairest model for products whose value and cost both scale with volume.
Use it for APIs, infrastructure and workloads that swing month to month. Firebase's Blaze plan is a familiar case: it is pay as you go, and you still get the free quotas before it starts charging. For a buyer, the appeal is low entry cost. For you, the appeal is that large customers pay more without a sales negotiation.
The downside is bill shock and revenue that is hard to forecast. Finance teams in smaller companies dislike open-ended invoices, so many usage-based vendors add spending caps, alerts or committed-volume discounts. We explain what drives that kind of bill in our guide to Supabase pricing and what a startup actually pays as it grows.
This is the most demanding model to engineer. You need to:
Stripe Billing, which is billing software with a built-in payment system, supports metered subscriptions, so you rarely need to write the invoicing engine yourself. The metering, however, is still your code. Budget for it as a real feature, not a configuration job.
Freemium gives away a free plan permanently and charges for upgrades. It trades short-term revenue for reach: the free plan is the marketing, and a share of free users convert when they hit limits or need more. It suits products that spread through use and sharing.
Freemium works when the marginal cost of a free user is low and the product gets better as more people use it. Dropbox is the classic example, with a free storage plan that users outgrow and a referral loop that spreads it. Slack's free plan, by its published structure, has no limit on seat numbers, so the upgrade pressure comes from other limits.
The Tuck School of Business at Dartmouth looked at how B2B SaaS CEOs should assess the freemium opportunity, and it describes the core mechanic well: customers try certain features free before deciding to pay. For a small team with no large marketing budget, that mechanic only pays off if free users cost almost nothing to serve.
Our view: most bootstrapped B2B founders in the UK and Northern Europe should avoid permanent freemium. A free trial, or a low-cost entry tier, gives similar learning with far less support load and infrastructure spend. Freemium is a funded-growth tactic.
Freemium needs everything tiered pricing needs, plus abuse control. Expect rate limits, signup verification, storage caps and a clear rule for dormant free accounts. Because free users still cost compute and support time, you also need usage dashboards so you can see what the free tier really costs you.
Upgrade prompts are part of the product here. The moment a user reaches a limit is your best conversion point, so design that screen carefully with your UX team.
Hybrid pricing combines a predictable base fee with variable charges. The base covers the plan and an included allowance; usage, seats or add-ons are billed on top. It is increasingly common because it gives customers a stable core bill and gives you revenue that grows with consumption.
Hybrid fits products with a real fixed value (a platform, a workspace, a dashboard) and a variable cost driver (data, messages, compute). Supabase works this way: a monthly plan fee, then usage charges once you pass the allowances included in that plan, tied to things like database size, egress, storage and monthly active users.
Use hybrid when pure usage pricing would scare buyers but flat pricing would lose money on heavy customers. The risk is complexity. If a prospect cannot estimate their own bill after reading your pricing page, you have gone too far.
Hybrid asks for everything: plan entitlements, seat or unit counts, usage metering and invoices that combine fixed and variable lines. The tricky part is explaining the invoice. Each line should map to something the customer can see in the product, such as "12 seats" or "48,200 events over the included 40,000", so finance teams can verify it.
Our advice is to build hybrid in stages. Launch with tiers and one metered dimension, watch how customers use it, then add a second dimension only if the data supports it.
Per-feature pricing charges extra for specific capabilities or modules. Customers start with a core product and add what they need, such as advanced reporting, automation, single sign-on or priority support. It aligns price with the features that create the most value for a given customer.
This model fits products with clearly separable modules and customers who need different combinations. Atlassian's Jira Cloud Premium is a useful reference point: Atlassian describes it as adding Atlassian Intelligence, cross-project planning, automation and 24/7 Premium Support on top of the base product.
In practice, per-feature pricing is usually blended into tiers. Pure à la carte pricing gets confusing fast, because customers must work out which features they need and how they combine. A small number of add-ons on top of tiers is easier to sell.
Per-feature pricing makes feature flags a billing concern. Each paid capability needs a flag linked to the account's subscription, checked in both the API and the interface. Disabled features should show a clear upgrade prompt, not a broken screen.
It also affects architecture. If features are tangled together, selling them separately becomes painful. This is one reason we encourage clean module boundaries early, which connects to the trade-offs in our post on monolith vs microservices for SaaS startups.
Choose the model whose charge grows with the value your customer receives, then check that you can meter and explain it. Start with your value metric, test it against your cost drivers and customer mix, and pick the simplest model that passes. Complexity can be added later; removing it from live customers is hard.
Imagine a UK invoicing tool for small accounting practices. Its early customers have 3, 12 and 40 users, and each user sends roughly the same number of invoices. Value follows team size, and cost does not spike with activity. Per seat would work, but a three-tier plan is better: it lets a three-person practice start small and gives the 40-user firm a plan with audit logs and priority support.
Now imagine the same company adds an e-signature feature that costs a third-party fee per document. That new cost scales with use, so a metered add-on on top of the tiers makes sense. The result is a hybrid, reached in two steps rather than one big design.
Pricing is partly an experiment. Even with a clear value metric, you will not know the right price points or limits until real customers push on them. Plan to review pricing every few months in the first year, and treat the first version as a hypothesis. It also pays to keep early customers on their original plan for a defined period so changes do not feel like a bait and switch.
Pricing logic costs more to build as the model gets more precise. Flat rate is the lightest; tiered and per seat add plan limits and seat management; usage-based and hybrid add metering, storage and reconciliation. The exact figure depends on your scope, so ask for a quote broken down by billing, metering and plan limits.
We do not quote prices in articles because each product differs. What we can describe is where the effort goes. Three buckets cover almost every pricing build:
For an MVP, we recommend building only the first bucket and a thin slice of the second. You can charge manually or with a simple subscription while you learn what customers value. Our breakdown of the cost to build a SaaS MVP in the Netherlands shows how billing sits within the wider scope.
The stack matters less than the discipline. With React and Next.js on the front end, Node.js for the entitlement and metering services and Supabase for data and authentication, billing state lives in one database and one set of tested functions. That keeps invoices traceable when a customer asks why they were charged.
Buyers in the UK, the Netherlands and the Nordics tend to expect clear, upfront pricing. In the UK, the Competition and Markets Authority publishes guidance on complying with the law on unfair commercial practices relating to price transparency. Read it before you design your pricing page, and take legal advice on how it applies to your product.
A few practical points follow from this for SaaS teams selling across Europe:
Our team works from India with overlap into CET afternoons, which suits the working hours of most UK and Northern European product teams. That overlap helps when billing edge cases need a same-day answer.
For most MVPs, tiered or per-seat pricing is the best start. Both are easy to explain, simple to bill and cheap to build compared with usage-based or hybrid models. Launch with two or three plans, learn what customers value, and add metering only when your costs or customer feedback call for it.
Yes, you can change models later, but it is easier before you have many customers. Plan for it by keeping plan logic in one entitlements module, storing usage data from the start and grandfathering existing customers on their current plan for a stated period, so the change does not feel abrupt.
Supabase uses a hybrid model: a flat monthly fee for your plan, then usage charges once you pass the included allowances. The bill depends on database size, data egress, monthly active users, storage and compute size. We cover the cost drivers in detail in our guide linked earlier in this article, so check current figures on the Supabase pricing page.
Most SaaS startups should stay on a well-structured monolith until team size or scaling pain forces a split. Billing and metering are a good early candidate to isolate as a module, not necessarily a separate service. Split only when separate teams need to deploy independently or one component has very different load.
A pricing page is only as good as the billing, plan limits and metering behind it. If you are choosing between these SaaS pricing models, we can help you scope what each one means to build before you commit. Our web development service covers full SaaS platforms in React, Next.js, Node.js and Supabase, and our UI/UX design service covers upgrade prompts and usage screens that convert.
If your product also needs a mobile companion, our cross-platform app development uses React Native, with one codebase for two platforms. You can browse our projects, see all services or read more in our blog.
Ready to price and build with confidence? Contact Axire Infotech with a short description of your product and customers. We respond to all inquiries within 2 hours during business hours, and we will tell you which pricing model we would build first and why.
Let's discuss your project and create something amazing together.
