Most tiered pricing problems show up as engineering problems. Marketing wants to move a feature from Growth to Starter, and that turns into a sprint because the gate is a boolean in three services. Sales wants a limit raised for one account, and that becomes a deploy because the limit is a constant. Meanwhile the entry plan does too much, the top plan does too little, and nobody upgrades.
The structure of the tiers and the system that enforces them are the same design problem. Getting the first right and the second wrong means the pricing page stops matching the product within two quarters.
What makes a tiered pricing model work?
A tier model works when each tier maps to a real customer segment, limits are set from observed usage rather than invented, features are placed by value rather than by what's easy to gate, and the whole thing is stored as data so changing it doesn't require a release. The pricing page is the visible half. The entitlement system is the half that decides whether you can iterate.
The design constraints
A value metric that tracks customer outcomes
The number that separates tiers should be something a customer can predict and something that grows as they get more value from the product. API calls, active users, projects, or messages processed all work. Anything a customer can't estimate before signing up will be estimated wrong, and the correction arrives as a support ticket.
Feature placement that doesn't feel punitive
Do not gate things customers expect at any paid level. Locking a basic capability behind an upgrade reads as a tax rather than a feature, and it produces complaints instead of conversions. Reserve gating for capabilities that genuinely cost more to deliver or that only matter at scale.
A useful split:
- Table stakes. Available on every paid plan. Gating these costs more goodwill than it earns revenue.
- High impact. Capabilities that matter once a customer is scaling. These belong to the middle and top tiers.
- Security, control, and integrations. SSO, audit logs, role-based access, private deployment. These map to the buyer at the top tier and are the usual reason they're there.
Limits derived from actual usage
Set limits from your usage distribution, not from round numbers. A limit that sits where real customers naturally cross it produces upgrades that feel earned. A limit set arbitrarily below where people work produces churn and a reputation for nickel-and-diming.
Whatever you pick, warn before the wall. A customer who gets told at 80% has time to decide. A customer who finds out at 100% has an outage.
Tiers that mirror segments
Three tiers covers most products, because each one should answer a different buyer.
- Free or Starter. Limited but genuinely functional. Its job is to let someone succeed once.
- Growth or Pro. The default choice and the main revenue line. Priced and packaged for the segment you actually serve.
- Advanced or Enterprise. High scale, negotiated terms, security and control requirements.
If a tier can't be described in one sentence with a named buyer, it's an internal artifact rather than a plan.
Price ratios that read at a glance
Simple multiples make progression legible. Starter at 1x, Growth at 2x to 3x, Advanced at 4x to 5x is a common shape because a buyer can compare the steps without doing arithmetic. Random gaps make the page feel arbitrary even when the numbers are well reasoned.
Support as part of the package
Response times and support channels are frequently the reason a larger customer moves up a tier, and they're cheaper to differentiate than features are. Make the difference explicit on the page rather than implied.
Building it: seven steps
1. Name the objective. Higher ARPU, cleaner segmentation, or less sales friction. These pull in different directions, so pick one to optimize. Vague goals produce tiers that are defensible in a meeting and confusing on a pricing page.
2. Segment, then pick the metric. Three or four segments based on real usage maturity. Talk to customers in each about what they rely on and what they'd pay more for.
3. Design three tiers with clear roles. Each needs a target user, a purpose, and an upgrade trigger you can point at in the data.
4. Place features and limits deliberately. Map every feature to table stakes, high impact, or control. Tie limits to the value metric so customers graduate by growing rather than by hitting a wall.
5. Price from value, bounded by cost. Your floor is the unit cost plus the margin you need. Your ceiling is the value the product delivers to your largest customers. Pick inside that range and validate against current accounts before publishing.
6. Ship it as configuration. This is the step that decides how much the next five changes cost. More below.
7. Watch behaviour and iterate. Track signups, upgrades, downgrades, limit hits, and support volume per tier. If Growth takes every upgrade and Advanced sits unused, the feature split is wrong. If customers hit a limit in week one, the limit is wrong.
The implementation that decides whether you can iterate
A tier is two things in the system: a set of prices, and a set of entitlements that the product checks at runtime.
The prices are the easy half. The entitlements are where teams paint themselves into a corner, usually by encoding the plan in application code:
# The version that guarantees a sprint per pricing change
if user.plan == "pro":
max_projects = 25
elif user.plan == "enterprise":
max_projects = 500
else:
max_projects = 3
Every limit change is a deploy. Every new plan touches every service holding one of these blocks. A one-off limit for a negotiated deal is either a hardcoded special case or a fourth plan nobody wanted.
The alternative is to treat entitlements as data the product reads:
curl --request GET \
--url 'https://api.cloud.flexprice.io/v1/customers/external/cust_123/entitlements' \
--header 'x-api-key: <your_api_key>'
That is the customer entitlements endpoint, keyed by your own customer identifier so the gate can run at the edge. Swap the host for us.api.flexprice.io on the US region. The plan defines the grant, the customer's subscription resolves to a set of entitlements, and the product asks what this customer is allowed to do rather than inferring it from a plan name. Changing a limit becomes a configuration change that takes effect without a release, and raising a limit for one account is an override rather than a new SKU.
In Flexprice the primitive is an entitlement: a feature linked to a plan with its usage limit configured there rather than in your services. Linking features to plans covers how a tier gets assembled that way, and price overrides handle a negotiated deal at subscription creation without cloning the plan.
If a per-billing-period limit is too coarse, entitlement grants turn it into a quota per window, something like 1M tokens per 5 hours, independent of the billing cycle. Windows can stack, a webhook fires when a quota is exhausted, and usage past it bills as overage.
Usage limits also need real-time enforcement to be worth anything. A quota evaluated by a nightly job can be exceeded all day. That means the check sits in the request path with a latency budget, which is a reason to keep the entitlement lookup a cached read rather than a computation.
Why tiered pricing changed SaaS monetization
Revenue tracks customer growth. Flat pricing charges the same whether a customer barely logs in or runs your product as core infrastructure. Once usage varies widely across the base, one price is wrong for almost everyone.
One model serves both ends. Self-serve buyers want predictability and no surprises. Enterprise buyers want flexibility, control, and security. Tiers serve both without splitting the product into two.
Expansion happens without a sales motion. When tiers match customer maturity, the upgrade happens because the product got more important to their workflow. That's a very different conversation from an upgrade triggered by hitting a wall.
All three depend on the same thing: the ability to change the model without a release cycle. If moving a feature between plans requires engineering time, the pricing stops evolving and the packaging drifts away from the product.
Where Flexprice fits
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud.
For tiered pricing specifically, that means plans, prices, limits, and entitlements live as configuration the product queries, so a packaging change doesn't touch your services. Tiers also compose with usage-based charges, credit wallets, and negotiated enterprise terms on the same subscription, which matters when the three-tier page stops being enough.
Read Creating a plan to see the shape of a tier before deciding how to model yours.
Top comments (0)