SaaS pricing tiers: designing plans users understand
A pricing page is a product decision wearing a marketing outfit. The tiers you define become database columns, quota checks, and invoice line items for years, so the plan structure deserves the same scrutiny as the schema behind it. We've shipped billing for several SaaS products, and the same patterns surface every time.
Two plan axes maximum
The most common mistake is a plan matrix: three tiers crossed with per-seat and per-month and usage add-ons. Every added dimension multiplies the combinations you have to price, test, and support. Pick the one or two variables that actually correlate with customer value. For team tools, that's usually seats plus one usage unit (API calls, exports, storage). Anything more and customers stop being able to answer "which plan do I need?", which is the question a pricing page exists to settle.
The middle tier should carry the bulk of customers: it prices the most common real usage. The low tier exists to make the middle look like the sensible choice, and the high tier exists for the account that needs everything without a negotiation.
Count things customers recognize
Quotas should be in units the customer thinks in. "5,000 records" and "100 MB of uploads" work because a customer can picture them. "2,500 credits, where a credit is one workflow execution excluding scheduled runs" does not, and it generates support tickets that all ask the same question.
The technical follow-through matters too: a limit nobody can see is a limit that feels arbitrary. Show current usage in the app, and warn before the cut-off rather than after. A hard stop with a confusing error converts an overage into a churned customer; a clear "you're at 90% of your plan" email converts it into an upgrade.
Make upgrade instant, downgrade careful
Upgrades should apply immediately and be prorated without a human in the loop. A user ready to pay more right now is the best moment in the whole customer relationship; don't park them in a form queue.
Downgrades are the trap. When a plan shrinks, the customer's data usually doesn't fit: they have 40 projects on a plan that allows 10. Options, in order of kindness:
- Keep the data, lock writes. The account goes read-only above the quota until they delete or upgrade. Nothing is lost; the constraint is visible.
- Grace period. Full features for the rest of the billing cycle, restrictions at renewal.
- Deletion as an explicit choice. Only when the product is inherently small and re-creating data is cheap.
Never silently delete or hide customer data because a card failed or a plan changed. That's a support conversation with refund requests attached, and the trust rarely comes back.
Annual plans and the details that decide disputes
Annual pricing buys you runway but borrows a promise: the customer expects that price to hold. The plan structure also has to survive the awkward cases:
- Proration on mid-cycle changes must match what the customer's own math says, or support hears about it.
- Seat counting needs a rule before launch: do removed seats free up mid-cycle, or at renewal? Both are defensible; vague is not.
- Failed payments need a defined sequence (retry, notify, restrict) so a temporary card problem doesn't delete a workspace.
- Taxes and invoices are decided by where the customer is, not where you are, and the invoice format is a legal requirement in much of the EU.
Verify the tiers and the page agree
The pricing page and the enforcement layer drift apart quietly. Someone changes a limit in config, and the marketing site says 100 while the app enforces 50. Treat plan definitions as a single source (a config file, a database table) and render pricing-page copy and in-app quotas from the same source. It's the same principle as feature flags: one definition, evaluated everywhere, so the page and the product can't disagree.
Pricing will be wrong the first time; every plan gets revised. The design goal is a structure that can change prices without a migration, and limits that customers can see and predict before they hit them.