Feature Flag

Code-level switch that enables or disables a feature without requiring code deployment. Infrastructure for safe experimentation, gradual rollout, and easy rollback.

What is a Feature Flag?

A feature flag is a conditional branch in code: if a configuration flag is enabled, execute the new feature; otherwise, execute the old behavior. Rather than bundling new features into releases and deploying them to all users simultaneously, flags allow you to ship code without immediately activating features, then gradually expose them to users or specific segments.

Feature flags are infrastructure for safe experimentation. With flags, you can deploy code to production (reducing deployment risk), then control exposure separately (reducing product risk). A bug in a flagged feature affects only the users who encounter it, not all users. If a metric tanks, you can disable the flag instantly without rolling back the deployment. This separation of deployment and activation is foundational to modern product development.

Flag Types & Use Cases

Static flags (on or off for all users) are useful for clean code—feature development can happen on a branch without cluttering main with disabled code. But the real power is in targeted flags: enable for a percentage of users (5% canary, 50% A/B test, 100% rollout), enable for specific users or segments (internal testing, beta users, specific accounts), or enable based on conditions (new users only, high-value accounts, specific browsers).

Flags also enable A/B testing without separate codebases. Variant A and Variant B live in the same code; the flag determines which code path a user takes. This avoids the complexity of maintaining two versions and ensures any difference is due to the change, not code divergence.

Technical Debt from Flags

Flags introduce technical debt if not managed carefully. Old flags (no longer being tested) clutter code and create confusion: is this flag still relevant? Should we remove it? Organizations that don’t discipline flag removal accumulate hundreds of unused flags, making code harder to understand and test.

The discipline is: every flag should have a clear lifecycle. When does it expire? When will we make a final decision (remove or permanent)? Maintaining a flag inventory (what each flag does, when it expires, who owns it) prevents debt accumulation.

Rollout Strategies

Flags enable sophisticated rollout patterns. Canary rollout (5% of users experience the new feature for 24 hours, then 25%, then 100%) reduces risk—if a bug affects 5% of users, you discover it before exposing 100%. Ramping (gradually increasing exposure over days) allows monitoring of system performance under increasing load. Targeted rollout (specific customer segments first) lets you validate with friendly customers before broad exposure.

Why It Matters for Product People

Feature flags decouple engineering deployment from product decisions. Engineers can merge code constantly (improving velocity); product can decide exposure (maintaining control). This separation allows rapid iteration without risk.

For executives, flags are insurance. A feature that degrades metrics can be disabled instantly. A feature that causes unexpected scaling issues can be disabled without rolling back a full deployment. This confidence enables faster iteration—you can launch and learn rather than planning endlessly before launch.

Feature flags are infrastructure for A/B testing and experiment-driven development. Cohort analysis often examines whether a flagged feature affects different segments differently. Funnel analysis tracks how a flagged feature affects conversion at each stage.