Feature flags for tiered products: a founder's guide

The cleanest mental model has two layers. The flag's default state is what any tier gets if you say nothing. Overrides are deliberate exceptions per tier. Keep defaults conservative — usually off for paid features, on for community features — so a brand-new tier starts safe.

Default off + override on for saas is the classic paid-feature shape (PRO_DASHBOARD_ENABLED). Default on + override off for saas is community-only behaviour, like anonymous telemetry prompts. No override at all means the feature is genuinely universal — and the matrix says so explicitly.

Flags rot when they're named vaguely and never retired. Enforce SCREAMING_SNAKE_CASE names that state the feature and the verb (SSO_SAML_LOGIN, USAGE_BILLING), require a one-line description, and review the tier matrix monthly. When a flag is on in every tier and the old path is dead, delete the flag and the dead branch of code in the same PR.

The matrix view matters more than any individual flag. It's the artifact you'll share with a new engineer, a prospective acquirer, or your own future self to answer 'what exactly does the paid version add?' — with per-tier resolution, that answer is a screenshot, not an afternoon of code reading.

tier·dev generates the per-tier config (JSON, YAML, or a dependency-free TypeScript snippet) from your matrix. Your CI sets PRODUCT_TIER per distribution and the same commit produces every edition. That's the whole trick: tiered packaging as a build input, not a codebase property.