SaaS Pricing Models and the Billing Engineering Behind Them
Key takeaway
Pick a pricing metric that grows with the value the customer receives and that they can predict in advance. Then respect the engineering: proration, mid-cycle plan changes, usage metering, and dunning are where most billing bugs — and most revenue leakage — actually occur.
Pricing is a commercial decision with an engineering bill attached. The model you choose determines how much billing code you'll maintain forever, and the most elegant pricing page is often the most expensive one to implement correctly.
The common models
- Per seat — simple to understand and forecast. Breaks when the product's value isn't proportional to headcount, and encourages account sharing.
- Usage-based — aligns cost with value and scales naturally, but customers dislike unpredictable bills and you need accurate, disputable metering.
- Tiered feature packages — easy to sell and upgrade, provided the tier boundaries match real customer segments rather than arbitrary feature splits.
- Platform fee plus usage — the hybrid most infrastructure products converge on: predictable base, variable upside.
Choosing the metric
- It should rise as the customer gets more value — not merely as they use more of your infrastructure.
- The customer should be able to predict it before the invoice arrives.
- It must be measurable in a way you could defend in a dispute.
- It shouldn't punish the behaviour you want — charging per integration discourages the very adoption that retains customers.
The billing engineering nobody scopes
- Proration on mid-cycle upgrades and downgrades — the most common source of billing complaints.
- Usage metering that is idempotent and reconcilable; double-counted events become refunds and lost trust.
- Trials, discounts, coupons, and grandfathered plans, which multiply the states your billing code must handle.
- Dunning for failed payments — retries, notifications, grace periods, and a defined path to suspension. Involuntary churn from expired cards is larger than most teams realise.
- Tax calculation by jurisdiction, and invoices that satisfy local requirements.
Practical advice
Use a billing provider rather than building a ledger; the edge cases are numerous and unglamorous. Keep pricing logic in configuration, not scattered through the codebase, because pricing changes more often than anything else in a SaaS product. And keep your own record of what was charged and why — when a customer disputes an invoice, "the provider says so" is not an answer.