SaaS Pricing Models: Per Seat, Usage-Based, and Everything In Between

Pricing Is a Product Decision

Most SaaS founders treat pricing as a finance or marketing problem. It's neither — it's a product problem. The pricing model you choose determines who can buy, how they buy, how they experience value, and how you scale revenue with your customers. Get it wrong and you'll either leave money on the table or create friction that prevents adoption.

The good news is there are only a handful of primary models, and the right one for your product isn't usually that hard to identify if you start with the right questions.

The Core Models

Per seat (per user) pricing. The customer pays a fixed amount per user per month. Salesforce, Slack, HubSpot, Notion — this is the dominant model for collaboration and productivity software. It's intuitive, easy to explain, and scales predictably with the customer's team size.

The challenge with per seat: it creates an incentive to reduce users. A $50/seat/month product with 20 users creates $1,000/month in motivation to share credentials, use service accounts, or limit who gets access. This is particularly acute in budget-sensitive companies, and it caps your revenue at the size of the buyer's team rather than the value they're getting.

Usage-based pricing. The customer pays for what they use — API calls, data processed, emails sent, AI tokens consumed. AWS, Twilio, Stripe, Snowflake — this model is dominant in infrastructure and API products. Revenue grows automatically as customers get more value. You don't need to convince anyone to buy more seats; as they use more, they pay more.

The challenge: unpredictable billing makes buyers nervous, especially enterprises that need to budget. Usage-based products often add complexity to their pricing to add a floor (minimum monthly commitment) or ceiling (enterprise flat rate), which creates a hybrid model whether you intended one or not.

Flat rate (tiered by feature). Three plans — Starter, Professional, Enterprise — with different feature sets at fixed monthly prices. This is what most SaaS products start with because it's easy to build and easy to explain. Pay $49/month for the basic plan or $199/month for everything.

The challenge: you're selling the same thing to the customer with 2 users and the customer with 200. The value delivered is wildly different; the price is the same. Tiered flat rate pricing leaves money on the table at the top and creates artificial constraints at the bottom.

Outcome-based pricing. You charge based on the business outcome the product produces — a percentage of revenue generated, a fee per qualified lead, a share of cost savings. This is the highest-value model when you can implement it because it directly aligns your price with the customer's value. It's also the hardest to measure and audit, and it requires deep trust between you and your customer.

How to Choose

Start with two questions: what is the primary unit of value your product creates, and who bears the cost sensitivity?

If value scales with users (a collaboration tool, a project management system), per seat is natural alignment. More users means more value delivered, so more users means more revenue.

If value scales with usage (API calls, transactions processed, data volume), usage-based is the honest model. It removes the friction of seat-based constraints and creates automatic expansion revenue.

If your product creates lumpy value — either you use it or you don't, and the value doesn't scale linearly — flat rate or tiered pricing may be the cleaner choice. A tool that runs your CI/CD pipeline doesn't get more valuable because you have more engineers using it; it's either running your builds or it isn't.

If your buyer is an enterprise with a procurement process, predictability matters more than optimization. Enterprise buyers want to know what they'll pay in Q3 so they can get it approved in Q2 planning. Usage-based pricing with no ceiling is hard to approve. Flat rate with an enterprise tier is easier.

The Hybrid Models That Work

Most mature SaaS products don't run pure versions of any single model. They run hybrids that combine the predictability buyers want with the expansion economics founders want.

Base + usage. A fixed monthly platform fee (predictable for the customer, guaranteed revenue for you) plus usage charges above a threshold. Twilio's core SMS/voice APIs work this way. Customers know they'll pay at least X and plan accordingly; heavy users pay proportionally more.

Per seat with usage limits. Each seat comes with a usage allocation (X API calls per user, Y data processed per month). This lets you serve light users cheaply and capture more value from heavy users who upgrade or pay overage.

Flat rate with seat expansion pricing. Plans are differentiated by features, but enterprise tiers add a per-seat component. You get simple pricing at the low end and scalable revenue at the high end.

The Technical Implications of Your Pricing Model

Your pricing model has engineering requirements that are easy to underestimate.

Usage-based pricing requires a usage metering system — tracking what each customer uses, in real time, with enough granularity to bill accurately. This is more complex than it sounds. You need to handle high volumes of events without losing data, aggregate them correctly by billing period, and report them accurately to both customers and your billing system (usually Stripe's metered billing).

Per seat pricing requires a seat management system — tracking active seats, handling seat additions and removals, and calculating prorated charges when plans change mid-billing cycle. Stripe's subscription API handles this well if you model it correctly from the start.

Tiered pricing by feature requires feature flagging — a system that controls which features each customer has access to based on their plan. Build a proper feature flag system early rather than scattering plan checks throughout the codebase.

Pricing Changes: How to Handle Them Without Losing Customers

You will change your pricing. Every SaaS product does, usually multiple times. The way to do it without destroying trust:

Grandfather existing customers. Customers on your old pricing should stay on it. Moving existing customers to a new, higher price is the fastest way to generate churn and public complaints. Make grandfathering the default policy.

Give ample notice. Any pricing change that affects existing customers needs at minimum 60-90 days notice, ideally more. This isn't just courtesy — it's the kind of change that affects people's budgets.

Offer an annual upgrade path. Before announcing a price increase, offer existing customers the opportunity to lock in current pricing for one or two years by switching to annual billing. This gives you cash up front and keeps customers happy.

Frame changes around value additions. "We're increasing prices to invest in X, Y, and Z improvements" lands better than "due to increased costs." Even if both are true.

Your pricing model is one of the highest-leverage decisions in your SaaS business — it affects every acquisition conversation, every expansion opportunity, and your annual revenue ceiling. If you're about to launch or re-price a SaaS product and want a second perspective, book a call at calendly.com/jamesrossjr.