Pricing is the part of building a SaaS company that everyone treats as an afterthought and almost everyone gets wrong the first time. Not because it is complicated in theory, but because there is no clean answer.
The right model depends on what you are building, who you are building it for, and what you are trying to achieve in the next twelve months. Change any one of those variables and the answer changes too.
This guide walks through all eight pricing models used by SaaS companies today, including time-based billing, a model that is growing in relevance as AI products and service-adjacent software mature. For each model, you will find the mechanics, who it works for, real examples, and the signals that tell you when it is time to move on.
How To Think About Choosing a Pricing Model
Before picking a model, answer three questions:
What is your value metric? The unit that grows as your customer gets more value from the product.
Who is your buyer? Technical users, business buyers, SMBs, or enterprise.
What is your growth motion? Product-led, sales-led, or hybrid.
Your answers narrow the field considerably. A developer tool with a bottom-up, product-led motion looks nothing like an enterprise CRM, and the pricing that works for one will actively hurt the other.
The 8 SaaS Pricing Models
1. Flat-Rate Pricing
One price. One plan. Everyone pays the same amount regardless of usage or team size.
How it works: You set a single monthly or annual price for full product access. There are no tiers, no overages, and no per-seat math.
Real example: Basecamp charges $299 per month for unlimited users, unlimited projects, and full access to every feature. That clarity is part of their brand.
Best for: Simple products with a uniform value proposition and companies optimizing for low sales overhead and easy decision-making.
The problem: Flat-rate pricing leaves money on the table at both ends. Power users who would pay five times more pay the same as light users. Light users who would buy at $29 per month do not buy at $99 per month. The moment your customer base splits into different segments, flat-rate pricing starts hurting growth.
2. Tiered Pricing
Two to four plans at different price points, each with a different feature set or usage threshold.
How it works: Customers self-select into a plan based on their needs. Each tier unlocks more features, higher limits, or dedicated support. Upgrades happen when customers hit limits or need functionality gated to a higher plan.
Real examples: Notion, Slack, HubSpot, Linear. Almost every major SaaS product uses tiers.
Best for: Products with diverse customer segments, any company running both a bottom-up motion and an upmarket push.
The failure mode: If your customers cluster at one tier and almost never upgrade, your tier structure is not mapping to how value is actually delivered. The upgrade trigger needs to be real, not artificial.
3. Per-Seat Pricing
Charge per user. Billing scales as the team grows.
How it works: Each additional person added to the workspace adds to the monthly bill. The model is predictable for the vendor and intuitively scalable for the buyer.
Real examples: Salesforce, Zoom, most B2B SaaS tools built before 2022.
Best for: Collaboration tools, CRMs, project management software where every user genuinely participates and adds value by being present in the system.
The 2025 problem: AI has broken the seat model in meaningful ways. When one person with an AI tool does the work of ten, seat count no longer maps to value delivered. Companies building AI-native products are moving away from per-seat pricing because it penalizes adoption rather than rewarding it.
4. Usage-Based Pricing
Customers pay for what they consume. The billing metric is tied directly to actual product use.
How it works: You define a measurable unit (API calls, tokens, messages sent, rows processed, gigabytes stored) and charge customers a rate per unit. Bills vary month to month based on actual consumption.
Real examples: AWS, Twilio, OpenAI, Stripe.
Best for: Infrastructure products, developer tools, AI APIs, and any product where usage varies significantly across customers and the cost to serve scales with that usage.
The trade-off: Revenue becomes harder to predict. Customers can also throttle usage when budgets tighten, which creates a natural ceiling on growth unless your product is deeply embedded in their operations before cost becomes a concern.
According to OpenView's research, over 60% of SaaS companies with ARR above $10 million now incorporate some usage-based element in their pricing structure.
5. Freemium
A free tier that exists indefinitely alongside paid plans. The free product delivers genuine value. Paid upgrades unlock more.
How it works: Users adopt the product at no cost. They hit natural limits (seats, storage, features, collaboration) and upgrade when those limits affect their work.
Real examples: Notion, Figma, Calendly, Linear.
Best for: Consumer-adjacent SaaS, developer tools, and products with strong viral or collaborative mechanics where the free tier does real marketing work.
The key distinction: Freemium is not a pricing model. It is a distribution strategy. It works when the product has genuine word-of-mouth mechanics or when its collaborative nature creates upgrade pressure organically. An overly generous free tier removes the upgrade trigger. An overly restrictive one does not generate adoption.
6. Pay-As-You-Go
Pure consumption pricing. No subscriptions, no commitments, no monthly minimums.
How it works: Customers use the product and pay only for what they consume in a given period. There is no baseline charge. Zero usage means a zero bill.
Real examples: Twilio, AWS Lambda, many infrastructure and communication platforms.
Best for: Products with low acquisition costs, strong developer adoption, and use cases where customers genuinely want to test before committing.
The risk: Customers treat pay-as-you-go products as utilities and optimize spend aggressively as costs scale up. Without a commitment structure, there is limited switching friction. This model works best when the product becomes embedded in workflows before cost optimization becomes a priority.
7. Hybrid Pricing
A base subscription covers access and core features. Usage above a threshold triggers additional charges.
How it works: Customers pay a predictable monthly fee that covers typical use. Heavy or high-value usage generates variable charges on top of the base.
Real examples: Snowflake charges compute credits per query on top of storage. Stripe charges a flat monthly fee for Radar plus per-transaction fees. Twilio bundles a monthly commitment with per-message overages.
Best for: Products with a predictable baseline use case and a high-variance power-use case within the same customer base.
Why most mature SaaS converges here: Hybrid pricing solves the core tension in SaaS billing. Subscriptions give vendors predictable revenue. Usage-based components let vendors capture the upside from customers getting outsized value. The base fee should cover the typical user. Overages should only trigger when the customer is genuinely in a high-value workflow.
8. Time-Based Billing
Customers are charged by time spent: per minute, per hour, or per active session.
How it works: A session starts when a user engages with the product. Billing accrues based on time elapsed. The session ends when the user leaves, and the charge reflects the duration.
Real examples:
AI legal research platforms charging per research hour (Lexi AI, Billables AI)
Tutoring and coaching SaaS products billing per session or per active minute
Autonomous AI agent products where tasks run for minutes to hours and the value delivered correlates directly with compute and session time
Interactive content platforms where engagement time is the value unit
Best for: Any product where the value delivered is a function of time spent. AI agents, session-based tools, educational platforms, interactive consultations, and any SaaS adjacent to professional services.
Why this model is growing: As AI agents take on longer, autonomous tasks with real-world consequences, time is becoming a legitimate billing unit. Billing per session or per hour is more honest than billing per seat for a product that replaces labor. The value is not in having access; it is in what the product does during the time it runs.
The infrastructure challenge: Most billing infrastructure was designed for subscriptions. Building time-based billing on top of Stripe from scratch requires custom session management, access control, and payment flow logic. This is nontrivial engineering for most early-stage teams.
This is where tiun becomes relevant. tiun is built specifically for SaaS and AI companies and natively supports time-based billing as a first-class product type alongside subscriptions, through the same SDK integration. You define a rate per session, call tiun.start() from your frontend, and tiun handles the payment UI, session tracking, access control, and billing automatically. No backend to build, no webhook logic to maintain. For any product monetizing on session time, this removes a significant engineering lift.
How to Choose at Your Stage
Pre-product-market fit: Simplicity beats sophistication. Flat-rate or simple tiered pricing lets you move fast and focus on learning what customers actually value. Do not try to optimize pricing before you have validated the product.
At product-market fit: Your data starts to tell you which customers extract the most value and which pricing model reflects that. This is when you migrate toward a model aligned with your actual value metric rather than the easiest one to implement.
At scale: Most successful SaaS products converge on a hybrid model. Subscriptions provide a revenue floor. Usage-based or time-based components capture the upside from your heaviest users and maintain alignment between price and value.
When To Change Your Pricing Model
Three signals suggest it is time to switch:
Customers hit limits and churn instead of upgrading. Your tier structure is not matching how value is delivered.
Your best customers pay the same as your marginal ones. Flat-rate pricing is leaving real revenue on the table.
Acquisition cost drops when you reduce friction at the bottom. A freemium or pay-as-you-go model may be the right distribution layer.
Test pricing changes on new cohorts before rolling them out broadly. Grandfathering existing customers while moving new customers to a new model is the cleanest way to run the experiment without creating churn risk.
The Infrastructure Question
Choosing the right pricing model is only half the problem. Implementing it is the other half.
Most early-stage SaaS teams underestimate how much engineering time goes into billing infrastructure: checkout flows, authentication, access control, webhook handling, and the reconciliation logic that keeps everything in sync. Every pricing model has different infrastructure requirements, and switching models later often means rebuilding significant portions of the billing stack.
tiun approaches this differently. It is a unified backend for SaaS and AI companies that handles authentication, payments, customer data, and billing in one system. Both subscription and time-based billing are native product types through the same SDK integration. For early-stage teams deciding between a subscription and a time-based model, tiun removes the infrastructure cost from that decision entirely.
Summary
Model | Best for | Value metric |
|---|---|---|
Flat-rate | Simple products, low complexity | Full access |
Tiered | Multi-segment products | Feature set |
Per-seat | Collaboration and team tools | Users |
Usage-based | Infrastructure, APIs, AI tools | Consumption |
Freemium | PLG with viral mechanics | Conversion |
Pay-as-you-go | Low commitment adoption | Consumption |
Hybrid | Mature SaaS with broad user base | Base + consumption |
Time-based | AI agents, sessions, service-adjacent | Time spent |
Frequently Asked Questions
Can a SaaS company use more than one pricing model at the same time?
Yes, and most mature ones do. A freemium tier sits on top of a tiered subscription structure. A per-seat base plan gets combined with usage-based overages. The hybrid model described above is essentially two models running in parallel. The question is not whether to combine models but whether the combination is legible to your buyer. If a customer cannot quickly understand what their bill will be and why, the complexity is costing you conversions. Keep the primary billing logic simple and layer in secondary components only when you have the data to justify them.
What is the difference between usage-based pricing and pay-as-you-go?
Usage-based pricing is the broader category. It means billing scales with consumption, but it can still involve a base subscription, committed spend tiers, or volume discounts. Pay-as-you-go is the purest form: no base fee, no commitment, no minimum. You use it, you pay for it. Nothing if you do not. AWS Lambda is pay-as-you-go. Snowflake is usage-based with commit options. Most companies start with pay-as-you-go for simplicity and migrate toward usage-based with commitments once they have enough customers to model predictable baseline consumption.
When does per-seat pricing stop making sense for AI products?
Per-seat pricing stops making sense when a single user with your product produces output that previously required a team. The seat count no longer maps to value delivered, and customers who are getting enormous ROI from one or two seats are dramatically underpaying. The signal to watch is seat-to-output ratio. If your best customers are doing ten times the work of average customers on the same number of seats, you are likely missing a usage or outcome-based component. Most AI-native companies are moving toward consumption metrics (tokens, tasks, sessions, or hours) precisely because seats were designed for a world where humans were the unit of production.
How hard is it to switch pricing models after launch?
Harder than most founders expect, for two reasons. First, there is the customer communication problem: existing users have anchored to a price and a model, and changes require careful framing to avoid churn. The standard approach is to grandfather existing customers on their current plan indefinitely and move new customers to the new model. Second, there is the infrastructure problem: your billing system was built around your original model, and migrating to a fundamentally different one often means rebuilding checkout, access control, and billing logic. This is why getting the infrastructure layer right early matters. A billing backend that supports multiple billing types natively makes a model switch a configuration change rather than an engineering project.
There is no permanently correct pricing model. The companies that get it right treat pricing as a product decision: something they measure, test, and adjust as their product and customer base evolves. Start with the model that creates the least friction for your first customers. Let the data tell you when to change.