SaaS · Saas

Tiered Pricing — A Field Guide

How to design SaaS pricing tiers that hold up: feature-gating vs usage-gating vs seat-based, the good-better-best pattern, and the mistakes that make tiers a tax on your sales team instead of a growth lever.

John Kihiu12 min read

Most SaaS companies back into their pricing tiers rather than designing them. Someone picks three price points that feel roughly right, engineering gates whatever features are easiest to flag-check, and eighteen months later sales is discounting the top tier by 40% because nobody can articulate why it costs three times as much as the middle one. Tiered pricing is a design problem before it's a pricing problem — the question isn't "what should we charge" so much as "what is each buyer type actually willing to pay for, and how do we make that legible on one page."

The three gating mechanisms, and what each one signals

There are three basic ways to differentiate tiers: gate by feature (higher tiers unlock capabilities), gate by usage (higher tiers unlock more volume — seats, API calls, storage, records), or gate by seat count (price scales with headcount regardless of usage). Most real pricing pages blend two of these, but which one you lead with signals something about your value metric. Feature-gating works when advanced capability genuinely correlates with sophistication — SSO and audit logs for the compliance-conscious enterprise buyer, for instance. Usage-gating works when your cost to serve scales with volume and the customer's value scales with it too. Seat-based gating is the laziest of the three and the most common, because it's trivial to implement, but it breaks down badly for tools that a few power users drive value from on behalf of a whole team — you end up either under-pricing (one seat, huge value extracted) or forcing customers to buy seats for people who barely log in.

Pick the gate that matches the value metric

Before choosing what to gate, write down the one number that best correlates with the value the customer gets from the product — records processed, revenue managed, tickets resolved, seats actively used. That number is what your tiers should scale against. If you can't name it, you're not ready to design tiers yet; you're ready to gate on whatever's convenient, which is how you end up with a $49 plan that includes API access and a $199 plan that only adds a slightly nicer dashboard.

Good-better-best: why three tiers works

The good-better-best pattern persists because it exploits a well-documented pricing psychology effect: buyers anchor against the extremes and default toward the middle. A three-tier ladder — call it Starter, Growth, Scale — gives most buyers exactly two real choices, because the top tier mostly exists to make the middle tier look reasonable and to catch the handful of customers who need everything. This is also why removing the top tier often drops average deal size: it's not there to sell in volume, it's there to shift the anchor. The practical failure mode isn't having three tiers, it's having five or six, where by tier four nobody remembers what's different from tier three and the sales conversation turns into a feature-comparison scavenger hunt instead of a value conversation.

Mistake: too many tiers, or tiers that don't map to a buyer

Every additional tier needs to correspond to a genuinely distinct buyer persona with a genuinely distinct willingness to pay — not just "a bit more than the last one." A common failure pattern: a company adds a fourth tier to capture a specific enterprise deal, ships it as a public price point, and now has a tier nobody self-serves into because it was designed around one customer's negotiated terms. The tiers that hold up over years are the ones built from the buyer segments you can name in one sentence: the solo user testing the product, the small team that needs collaboration, the company that needs governance and support SLAs. If you can't map a tier to a persona like that, it's not a tier, it's a discount level wearing a tier's clothing.

Mistake: gating the feature that blocks adoption, not the one that signals value

The single most damaging tiering mistake is gating something a prospect needs to evaluate the product, rather than something they need once they've committed to it. Putting integrations, API access, or basic reporting behind a paywall often kills deals before the buyer ever sees enough value to justify paying — they bounce off the free or entry tier without ever experiencing the thing that would have converted them. The features that belong behind a paywall are the ones that matter more as usage and organizational complexity grow: advanced permissions, audit trails, dedicated support, higher rate limits. A useful test: if free or Starter users churn citing "I couldn't do X," X was probably gated too aggressively; if they churn citing "we outgrew it," your gating is working as intended.

Anchoring works until it looks like a trick

Deliberately overpricing a mediocre middle tier to make the top tier look like a deal is a real technique, but it only survives contact with a sophisticated buyer once. B2B buyers who evaluate multiple vendors will build spreadsheets comparing your tiers line by line — if the price ladder only makes sense as a psychological nudge and not as an honest reflection of cost-to-serve and value delivered, you'll win the first sale and lose the renewal negotiation when procurement notices.

Wrapping up

Tiered pricing works when each tier maps to a real buyer segment and gates on the value metric that segment actually cares about — not when it's three arbitrary price points with features sprinkled in whatever order was easiest to build. Lead with the gating mechanism that matches how your product delivers value (feature, usage, or seats), keep the ladder to three rungs unless a fourth genuinely represents a new persona, and never gate the feature a prospect needs to see value in the first place. Get those right and the pricing page does half the sales team's job for them; get them wrong and every deal becomes a custom negotiation.

John Kihiu
Acumatica ERP Developer · Laravel Engineer

Independent software engineer in Nairobi specialising in Acumatica customisations, Laravel backends, and tax fiscalisation integrations across East and Southern Africa.