What Are Feature Flags?
Ship code to production without making it visible to users.
Feature flags are conditional code blocks that enable or disable functionality at runtime without requiring a new deployment. They decouple deploy from release — the most important property for teams aiming to deploy frequently with low risk.
Definition
What feature flags are and why platform teams care about them
A feature flag is a conditional in code or configuration that determines whether a piece of functionality is active. At its simplest, it is an if-statement that checks a configuration value. In more sophisticated implementations, it is a call to an external service that evaluates context — user identity, geographic region, percentage rollout, experiment group — and returns a boolean or a variant.
The core property that makes feature flags valuable for platform engineering: they decouple deployment from release. Without flags, every code deployment is simultaneously a release — code that goes to production is immediately visible to users. With flags, code can live in production in an inactive state, which means the deployment is low-risk and the release is a separate, controlled event that can be staged, monitored, and reversed instantly without a code rollback.
This property is what makes trunk-based development practical at scale. When every merged change can be deployed safely (because sensitive work is behind a flag), teams can merge frequently to main rather than maintaining long-lived feature branches. Long-lived branches are a merge complexity tax; trunk-based development avoids it.
Types of feature flags
Four distinct flag categories
Based on Pete Hodgson's taxonomy in the foundational "Feature Toggles" article on martinfowler.com.
Release flags
Control visibility of a new feature to users. Code is deployed to production; the flag determines who sees it. Used for progressive rollouts (1% of users → 10% → 100%), beta programs, and A/B tests. Release flags are temporary — they should be removed once the rollout is complete.
Experiment flags
Assign users to a control or treatment group for an experiment. Used for A/B testing and multivariate testing. Experiment flags are controlled by a metrics or experimentation system that tracks outcomes per group. They are removed when the experiment concludes.
Ops flags
Control system behavior at runtime without a deployment. Circuit breakers, kill switches for expensive operations, traffic routing controls. Ops flags are often permanent — the ability to turn off an expensive feature or reroute traffic is operational capability the team wants to retain indefinitely.
Permission flags
Control which users or user groups have access to a feature based on entitlement. Premium feature gates, beta user groups, employee-only features. Permission flags tend to be long-lived and are often managed by the product or billing system rather than the platform.
Platform team governance
What platform teams own in the feature flag system
Flag naming conventions. Without a naming standard, flag names in a large codebase become opaque: new_dash, test_feature_v2, jira_123. A platform team defines the naming convention (service prefix, purpose category, ticket ID) so that any flag name is self-describing in production logs and monitoring.
Flag lifecycle management. The platform team defines the lifecycle: creation requires a documented purpose and expected removal date; flags past their expected removal date appear in an automated audit report; flags without a documented owner are quarantined. Without lifecycle governance, flags accumulate indefinitely and the codebase develops permanent dead code paths.
Audit logging. Every flag state change — who enabled it, when, for which users — should be logged. This is both a security requirement (changes to production behavior should be traceable) and a debugging aid (when an incident correlates with a flag change, the audit log makes that visible immediately).
Self-service flag creation tooling. In a mature platform, creating a new flag and enabling it for a specific user segment should not require a platform team ticket. The platform team builds the self-service surface; application teams use it. Flags that require a platform engineer to create are friction that limits adoption.
Common mistakes
Three ways feature flag systems go wrong
Flags that live forever
A release flag that was created for a rollout three years ago and never removed is now permanent dead code. Every developer reading that code has to decide whether the flag is safe to remove or whether some unknown behavior depends on it. Permanent flags are permanent complexity. The fix is lifecycle management: every flag has a removal date, and removal is treated as part of the feature ticket, not an optional follow-up.
Flags with no owner
When the engineer who created a flag leaves the team, nobody knows whether it is safe to clean up. Ownership records in the flag system prevent this. A flag without a current owner is a flag with unknown risk. Automated ownership reminders (quarterly: "you own 12 flags; 3 are past their expected removal date") keep the debt from accumulating silently.
Flags that affect performance without measurement
An ops flag that routes traffic to a new code path may introduce latency. Without before/after performance measurement baked into the rollout process, flag-introduced regressions are invisible until they have been in production long enough to affect SLOs. The rule: every flag that affects a performance-sensitive path should have a monitoring alert or SLO check tied to its state.
Common questions
Feature flags: direct answers
Are feature flags the same as feature toggles?
Yes — the terms are interchangeable. "Feature flag," "feature toggle," "feature switch," and "feature gate" all refer to the same concept: a conditional in code or configuration that controls whether a given piece of functionality is active. "Feature flag" is the most common term in the platform engineering context.
Should feature flags live in code or config?
For simple, short-lived flags, code-level conditionals with a config value read at startup are often sufficient. For flags that need to change without a deployment — toggling a feature on or off in production in seconds — a dedicated feature flag service is the appropriate tool. The rule: if the flag needs to change without a code deployment, it belongs in a runtime config system.
How do you manage feature flag tech debt?
Flag tech debt accumulates when flags are never removed after their purpose is served. The standard practice is to treat flag creation as a two-step process: create the flag, and simultaneously create a removal ticket. Flags should have a documented owner and an expected removal date. Some teams enforce a maximum flag age and require explicit sign-off to extend it.
Build the deployment platform your team needs
Feature flags, CI/CD golden paths, and deployment automation — wired together as a platform capability.
The Platform Foundation engagement builds the deployment infrastructure that lets your team ship with confidence.