the three parts: tiers, defaults, overrides
A tier is a named edition of your product — open-source, saas, pro — a label on one codebase, never a branch. Each flag carries a default state, which is what any tier gets when you say nothing, and overrides, which are deliberate per-tier exceptions.
The classic shapes: default off with saas overridden on (a paid feature like PRO_DASHBOARD_ENABLED); default on with saas overridden off (community-only behaviour like telemetry prompts); and no overrides at all, which documents that a feature is genuinely universal.
the matrix is the product
Lay flags down the rows and tiers across the columns and you get the artifact that makes the technique work: a complete, readable statement of what every edition contains. 'What exactly does the paid version add?' stops being an afternoon of code archaeology and becomes a screenshot.
From the matrix, tooling like tier·dev generates per-tier config — tiers.json, tiers.yaml, or a dependency-free code module — that you commit. Builds resolve their tier's block; a flag flip is a one-line diff someone approves.
when tier-based flagging is the wrong tool
If you need percentage rollouts, user targeting, or instant kill switches, you need runtime flag delivery — a different job (see the LaunchDarkly comparison below). And if you only ship one edition, plain feature flags cover you; tiers earn their keep the day your pricing page splits the product into versions.
frequently asked
- is this the same as a freemium plan gate?
- Related but lower in the stack. Plan gates check a customer's subscription at runtime inside one deployment; tier flags decide what each shipped edition contains in the first place. SaaS plans often layer plan gates on top of the saas tier's build.
- how many tiers do products actually use?
- Two or three covers almost everyone: open-source + saas is the core open-core shape, with pro or enterprise as a third column. Because a tier is one more column of values — not a new build pipeline — adding one later is cheap.
- what flag types does tier-based flagging need?
- Booleans cover the packaging job almost entirely — a feature is in an edition or it isn't. Numeric limits (seats, quotas) usually belong to runtime plan gates rather than build-time packaging.
Last updated June 12, 2026