Guide · Apps & software
SaaS pricing models and what they mean for your product architecture
Pricing is usually discussed as a marketing decision, but for a SaaS product it is also an engineering one. What you charge for — users, projects, requests, features — must be counted, limited, billed and reported by the software. Changing the pricing model after launch can mean changing the data model underneath. This guide describes common models and what each requires from the product.
[ 01 ]
In short
In short
- 01
Choose the billing unit — what grows with the value customers get — before building the core.
- 02
Per-user pricing is simple to explain; usage-based pricing aligns with value but needs reliable metering.
- 03
Tiers combine limits and features; they require a feature-flag and limits system.
- 04
Billing needs a payment provider that supports recurring payments for your market.
- 05
Build usage tracking and plan management from the first version, even if pricing changes later.
[ 02 ]
Guide
Common models
Flat rate
One price for everything. Simple to build and explain; leaves money on the table with large customers and may be expensive for small ones.
Per user (per seat)
Price multiplied by the number of users. Common for collaboration tools and business software. Requires counting active users per organisation and handling additions and removals mid-period. Customers may share accounts to save money, which is a signal the unit does not match value.
Tiered plans
Several plans with different limits and features — for example, Starter, Business, Enterprise. Requires feature flags per plan, limit enforcement and upgrade paths.
Usage-based
Price by consumption: messages sent, orders processed, storage used, API calls. Aligns price with value and scales with customers, but requires accurate metering, clear visibility for customers and predictable bills.
Hybrid
A base fee plus usage above included limits, or tiers with per-user pricing. Common in practice.
Choosing the billing unit
The best unit grows with the value the customer receives and is easy to understand: a booking system might charge per location or per specialist; a CRM per user; a messaging tool per message; an e-commerce platform per order or by revenue band. Consider how customers will perceive it and whether it encourages or discourages the behaviour you want.
What it means for architecture
- Organisations and users: the product must know which users belong to which customer. See multi-tenancy.
- Plans and features: a system to map plans to features and limits, changeable without deploying code.
- Metering: reliable counting of the billing unit, with history, for billing and for showing customers their usage.
- Limits: soft warnings and hard limits, with clear messages and upgrade options.
- Billing integration: subscriptions, invoices, proration on plan changes, failed payment handling, cancellations.
- Trials and discounts: time-limited access, coupons, annual vs monthly pricing.
- Analytics: revenue per customer, churn, expansion revenue.
Payments for SaaS in Azerbaijan
Recurring card payments depend on your payment provider's support for saved cards and subscriptions. International SaaS businesses often need a provider available to their legal entity — which may affect where the company is registered. See Stripe and PayPal in Azerbaijan. For B2B customers, invoicing with bank transfer is also common and must be supported.
Starting simple
For an MVP, one or two plans and manual invoicing can be enough to test willingness to pay. But the product should still record the billing unit and link users to organisations from the start, so the full model can be introduced without reworking the core. See defining MVP scope.
[ 03 ]
FAQ
Frequently asked questions
Should we show prices publicly?
For self-service SaaS, public pricing helps conversion. For enterprise products with custom terms, "contact us" is common, often with published entry-level plans.
Can we change our pricing later?
Yes, and most SaaS companies do. Architecture that separates plans, features and limits from code makes changes easier. Existing customers are often kept on old plans for a period.
Monthly or annual billing?
Offer both if possible. Annual billing improves cash flow and retention; monthly lowers the barrier to start.