Tier Design

How to structure pricing tiers using the Good-Better-Best pattern with the decoy effect to drive upgrades.

Why

The Good-Better-Best (GBB) tier structure is the most researched pricing pattern in SaaS because it reliably outperforms 2-tier and 4-tier designs. The mechanism is the decoy effect: the middle tier (Better) is priced to make the top tier (Best) look like a better deal per unit, so users who would have picked Good upgrade to Best. Example: Good $9 (3 projects), Better $29 (25 projects), Best $99 (200 projects) — Better at $1.16/project makes Best at $0.50/project look like a steal, so 40% of users pick Best vs 20% if Better did not exist. The tier boundaries must map to a single value dimension (projects, seats, API calls) so the user can compare without a feature matrix. The most common mistake is making the tiers differ on multiple dimensions (projects AND seats AND features), which creates a comparison problem that reduces conversion. One dimension, 3 tiers, 2-3x price gaps — this is the formula.

When

At launch, and whenever you add or remove a tier. Never run more than 3 published tiers — add a hidden 'Contact us' enterprise tier instead.

How

1. Pick the single value dimension: projects (usage), seats (team), or API calls (scale) — not storage or features, which are hard to compare
2. Set the tier limits on that dimension: Good=3, Better=25, Best=200 (roughly 8x and 8x gaps, so the jumps feel meaningful)
3. Set the prices with 2-3x gaps: $9, $29, $99 — the gaps must be large enough that the upgrade is a real decision, not a rounding error
4. Position Better as the decoy: its per-unit price ($1.16/project) should be worse than Best ($0.50/project), so Best looks like better value
5. Label Better as "Most popular" with a badge — social proof anchors users to the middle, and the decoy then pushes them to Best
6. Put all table-stakes features (auth, core tools, community) in every tier; differentiate only on the limit and 2-3 premium features
7. Add a 4th hidden tier: Enterprise = "Contact us" for > 50 seats, with SSO, audit log, SLA — do not publish a price
8. Test the tier boundaries with real usage data after 3 months: if 60% of Better users hit the 25-project limit, the limit is too low; if 5% hit it, it is too high

Example

# GBB tier structure (single dimension: projects)
const tiers = [
  { id: "good",    price: 9,  projects: 3,   perProject: 3.00, label: "Starter" },
  { id: "better",  price: 29, projects: 25,  perProject: 1.16, label: "Pro — Most popular" },
  { id: "best",    price: 99, projects: 200, perProject: 0.50, label: "Team" },
];
// Decoy: Better at $1.16/project makes Best at $0.50/project look like a steal
// Result: ~40% pick Best, ~45% pick Better, ~15% pick Good

# Pricing page layout (one screen, no comparison matrix)
# Starter    $9/mo     3 projects, community
# Pro        $29/mo    25 projects, AI coding, priority support   [Most popular]
# Team       $99/mo    200 projects, 10 seats, SSO, audit log
# Enterprise Contact  50+ seats, SLA, on-prem

Common Problems

⚠Differentiating tiers on multiple dimensions (projects AND seats AND features) — the user cannot compare without a matrix, and a matrix means decision paralysis. One dimension only.
⚠Equal price gaps ($19, $29, $39) — the gaps do not feel meaningful, so users pick the cheapest. Gaps must be 2-3x to make the upgrade a real decision.
⚠Not using the decoy effect — without a middle tier that makes the top tier look like better value, 80% of users pick the cheapest tier and you lose the upgrade revenue.

Best Practices

✓Use the GBB pattern with 2-3x price gaps and a single value dimension — this is the most-tested SaaS pricing structure and reliably outperforms alternatives.
✓Label the middle tier 'Most popular' — the social-proof badge anchors 50-60% of users to the middle, where the decoy then pushes them to the top tier.
✓Review tier boundaries quarterly against real usage — if the limits do not align with where users naturally cluster, the tiers are forcing artificial decisions.