Most pricing decisions in SaaS happen like this: the team looks at what the market leader is doing, what a recently successful competitor raised money with, or what the head of sales is comfortable explaining on a call. Then they pick that model.
That process produces pricing that feels defensible in a board meeting. It rarely produces pricing that matches the product's actual expansion mechanics.
Pricing is not a marketing decision. It is a structural decision that determines how your annual recurring revenue (ARR) grows inside existing accounts - or whether it grows at all.
Why Pricing Is Architecture, Not Marketing
Your pricing model determines three structural things that no amount of messaging work can override:
- Expansion mechanic - the specific mechanism by which a customer's spend grows over time
- Net dollar retention (NDR) ceiling - the mathematical maximum your existing-customer revenue can reach given the model
- Customer acquisition cost (CAC) payback structure - how quickly a new customer becomes profitable given the model's expansion curve
Get the pricing model wrong and you create a structural problem that looks like a sales problem, a retention problem, or a customer success problem. Teams respond by hiring more salespeople, rebuilding onboarding, or adding customer success headcount. None of those fixes work because the constraint is upstream of all of them.
For technical founders, think of it this way: your pricing model is like your database schema. You can build any application logic you want on top of it, but the schema constrains which queries are efficient and which are structurally impossible. A flat-rate pricing schema makes "expansion revenue" a structurally impossible query.
The 8 Pricing Models and What Each One Requires
1. Freemium
Works when three conditions exist simultaneously: the product delivers genuine individual value at zero cost, the market is large enough that a small conversion rate generates meaningful revenue, and the product has natural viral mechanics. Free users must cost near-nothing to serve.
When any condition is missing, freemium creates a resource drain. The worst case: a product requiring team adoption adds a free tier and discovers solo free users churn before the team ever activates.
Examples with correct structural DNA: Figma (instant individual value, viral through shared files), Zoom (instant value to one person, network effect from inviting others).
2. Per-Seat
Works when value scales roughly linearly with the number of users, and when a typical account has enough users to create natural expansion. The structural requirement is a multiplayer product where each additional licensed user gets distinct, daily value.
Per-seat fails structurally when your typical account has 1-3 users. No expansion lever. NDR from that segment is capped at whatever your churn rate allows.
3. Usage-Based
The most powerful expansion model for the right product type - and one of the most expensive mismatches for the wrong one. Works when consumption of a specific, measurable resource is directly proportional to the value delivered. Usage must also vary significantly across customers (by a factor of 10 or more).
The structural test: does a customer who gets more value also consume more of the measurable resource? Twilio (per API call) and Stripe (per transaction, at 2.9% + $0.30 per Stripe's official pricing) are canonical examples: as a customer's business grows, their spend grows automatically. No sales conversation required.
For developers building metered billing: your usage metric needs to be something the customer intuitively understands and can forecast. API calls, compute minutes, storage GB, events ingested - these work because they map to recognizable resources. "AI units" or opaque credit systems add friction because the customer cannot predict their bill.
4. Tiered (Flat-Rate Plans)
Works when you have multiple distinct buyer segments with genuinely different feature needs and willingness to pay. The structural requirement is real feature differentiation across tiers - not arbitrary feature locks.
5. Flat-Rate
One price. All features. Basecamp charges $299 per month (billed annually) for unlimited users and all features, per Basecamp's official pricing page. The structural cost is explicit: flat-rate pricing sets your NDR ceiling at approximately 100%. There is no expansion mechanic. Teams choosing flat-rate must compensate with low churn and efficient new customer acquisition.
6. Credit-Based
Credits purchased upfront and consumed across multiple features with different underlying costs. Most common in AI and ML products where compute cost varies by action type. OpenAI's API pricing uses this model: tokens are consumed at different rates depending on which model is called.
7. Per-Active-User
A variant of per-seat that charges only for users who perform an action during the billing period. Designed for organizations that provision broadly but use unevenly. Slack uses a version of this through its "fair billing" approach, crediting accounts for inactive seats.
8. Hybrid
Combines two pricing dimensions - typically a per-seat base alongside a usage component. Intercom's current pricing demonstrates this: a per-seat base fee (starting at $29/seat/month on the Essential plan) plus a $0.99 per-AI-resolution charge through its Fin AI agent, per Intercom's official pricing page.
The structural requirement: complexity that the customer can explain to their CFO (chief financial officer) on renewal.
The Three Most Expensive Mismatches
Mismatch 1: Usage-Based on a Single-Player Tool
Usage-based pricing assumes consumption grows as value grows. On a single-player product where one person uses it and the usage pattern is stable, consumption does not grow with business scale. Your billing system adds complexity without generating expansion revenue. NDR looks identical to what a flat-rate model would produce - except with higher support overhead from usage questions.
Mismatch 2: Per-Seat Where Most Accounts Have One User
The most common mismatch in early-stage SaaS. A team sees tools like Slack or Jira charging per seat and adopts the same model. Then they discover most accounts are single-user. The account pays for one seat. It will continue paying for one seat. No amount of customer success outreach changes that - it is structural.
The fix is not a different seat price. It is a different model - most likely tiered flat-rate with upgrade triggers based on features or usage volume, not user count.
Mismatch 3: Freemium on Team-Dependent Activation
If your product requires 3-5 team members before it delivers core value, a freemium model creates a structural conversion problem. A single user signs up. The product does not deliver value to a single user. The user churns before inviting the team.
The better structural fit: a free trial (time-limited, team-required) rather than a permanent free tier for individuals.
The Decision Framework
Work through these questions in sequence:
Q1: Does your product deliver meaningful value to a single user alone?
No -> per-seat, tiered, or hybrid. Freemium is high-risk.
Yes -> continue.
Q2: Does usage volume correlate directly with value delivered?
Yes -> usage-based worth evaluating.
No -> tiered or flat-rate.
Q3: Does a typical account have 5+ users?
Yes -> per-seat creates natural expansion.
No -> tiered flat-rate (upgrades driven by features, not headcount).
Q4: Does value vary enough across segments to justify multiple tiers?
Yes -> tiered pricing.
No -> flat-rate reduces friction.
Q5: Multiple consumable actions with different underlying costs?
Yes, AI/compute-intensive -> credit-based.
Simple consumption -> standard usage-based.
Five Questions to Ask Right Now
1. What percentage of your accounts have only one user - and does your current pricing model have any expansion lever for those accounts?
2. Does your usage-based metric actually grow as your customers get more value? Write down the metric you charge on. What happens to it when a customer's business doubles? If the answer is "nothing predictable," your usage-based model is not capturing expansion.
3. If a customer's team grows from 5 to 50, does your pricing model capture more revenue automatically? If not, you are relying entirely on proactive expansion conversations rather than structural mechanics.
4. What is the single most common reason a customer's spend increases? Your pricing model should be designed around that reason. If spend increases because teams grow, the unit should be seats. If spend increases because transaction volume grows, the unit should be usage.
5. Can your sales team explain your pricing model clearly in 60 seconds to a CFO? If not, your model may be adding buying friction.
Pricing figures cited: Stripe pricing from stripe.com/pricing; Basecamp pricing from basecamp.com/pricing; Intercom pricing from intercom.com/pricing.
This is Article 3 of 8 in the SaaS Product DNA series. Next: why 14-day trials work for Calendly and kill compliance tools - the activation trap.
If you found this useful, follow for the rest of this series. I am also building a classification toolkit that walks through all 10 dimensions with decision trees and a strategy implications matrix - details at [DNA_LANDING_PAGE_URL].
Top comments (0)