Pricing is one of the first decisions SaaS founders get wrong, not because they pick the wrong number, but because they pick the wrong model. The structure of how you charge matters as much as the amount. Get it wrong and you create friction at signup, leave money on the table, or build a product that's expensive to operate at scale.
Here's a clear breakdown of the main SaaS pricing models, the tradeoffs of each, and how to think about picking one when you're early and don't yet have much data.
Flat Rate Pricing
Flat rate is the simplest model: one product, one price, one plan. Everyone pays the same amount per month regardless of how much they use it or how many people are on their team.
The upside is simplicity. It's easy to explain, easy to sell, and easy to forecast. The downside is that it leaves value on the table. A small startup and a large enterprise using the same product are paying the same amount, which means you're either overcharging small customers or undercharging large ones. Flat rate works best for simple tools with a narrow, consistent use case.
Per Seat Pricing
Per seat pricing charges by the number of users. One seat costs a set amount per month. Add more users, pay more. This is the model used by most B2B tools, including Slack, Notion, and Linear.
It scales naturally with the size of the customer. A team of five pays less than a team of fifty. Revenue grows as the customer grows, without any extra selling effort. The risk is that teams try to minimise seat counts by sharing accounts, and larger teams sometimes resist the model because costs feel unpredictable as they hire. Consider offering team or company-wide pricing tiers for higher-volume customers to address this.
Usage-Based Pricing
Usage-based pricing charges customers based on how much they use the product. API calls, messages sent, rows processed, emails delivered. Twilio and Stripe are the most well-known examples.
The appeal is alignment: customers pay in proportion to the value they receive. Light users pay very little, and high-volume users pay a lot. This lowers the barrier to getting started, which can improve conversion rates significantly.
The challenge is predictability. Customers can't always forecast their monthly bill, which creates anxiety and can slow down purchasing decisions in larger organisations. Usage-based pricing also requires more infrastructure to meter and bill accurately. It tends to work best for developer tools and infrastructure products where usage is a clear proxy for value.
Freemium
Freemium offers a free tier with limited features or capacity, and paid plans for users who need more. Notion, Figma, and Calendly have all built large user bases this way.
The logic is that a large free user base creates organic growth through word of mouth and network effects, and a percentage of those users convert to paid over time. The problem for early-stage founders is that freemium is expensive to operate. Free users still generate support requests, infrastructure costs, and engineering overhead. If your conversion rate from free to paid is low, you can end up with a large, costly user base that doesn't generate meaningful revenue.
Freemium makes most sense when you have a strong network effect, low marginal cost per user, and a clear, compelling reason for free users to upgrade. It's rarely the right starting point for an MVP.
How to Choose When You Don't Have Data
Most early-stage founders don't have enough data to optimise their pricing model. That's fine. The goal at this stage isn't to find the perfect model. It's to find one that's good enough to start learning from.
Start with the model that matches how your customers naturally think about value. If they think in terms of team size, use per seat. If they think in terms of volume, use usage-based. If the value is the same regardless of usage, use flat rate. Keep it simple. You can always add tiers, introduce usage-based components, or restructure entirely once you have real data from paying customers.
At Cystall, we help early-stage founders build SaaS products and work through decisions exactly like this. If you're planning your first build and want to think through how pricing affects your product architecture, get in touch.