Feature Flags definition
Feature flags, also called feature toggles, are switches in code that turn functionality on or off at runtime without deploying new code. Teams use them to release features gradually, test with specific users, run experiments and disable a problematic feature instantly, separating the act of deploying code from the decision to release it to users.
How do feature flags work?
Code wraps a new behavior in a check: if the new checkout flag is enabled for this user, show the new checkout, otherwise show the old one. A feature flag service stores the rules, such as enabled for internal staff, for customers in India, or for 10 percent of users chosen consistently by ID. SDKs fetch or stream those rules and evaluate them locally, so checks are fast and changes take effect within seconds.
Because the flag is evaluated at runtime, product managers or engineers can change who sees a feature from a dashboard without a deployment. SDKs fall back to safe default values if the flag service is unreachable, so an outage at the provider does not break the application.
Types of feature flags
A widely cited article on feature toggles, published on Martin Fowler's website, groups flags by purpose and lifespan. The type determines how long a flag should live and who should control it. Mixing types under one naming scheme makes cleanup harder later.
- Release flags: hide unfinished or newly deployed features; short-lived.
- Experiment flags: split users between variants for A/B tests.
- Ops flags: kill switches and load-shedding controls for operations teams.
- Permission flags: enable features for specific plans, customers or beta groups; often long-lived.
Common feature flag use cases
Flags make trunk-based development practical: incomplete work merges to the main branch daily, hidden behind a flag, instead of living on long branches that are painful to merge. They enable dark launches, where new code runs in production without users seeing it, and beta programs for selected customers. Kill switches let teams turn off a failing feature or a struggling third-party integration in seconds, without a hotfix deployment.
Flags also support safe migrations, such as gradually moving reads from an old database to a new one while comparing results, and experiments that measure how a change affects conversion before it is rolled out to everyone. Both uses rely on reliable metrics for each user group.
Avoiding feature flag debt
Every flag adds a branch in the code and another combination to test. Teams that never remove flags end up with hundreds of stale toggles, confusing behavior and occasional incidents when an old flag is flipped by mistake. Treat flags as temporary unless they are deliberately permanent.
- Give every flag an owner, a description and an expected removal date.
- Remove release flags soon after a feature reaches all users.
- Avoid nesting flags inside other flags.
- Test both the on and off paths in automated tests.
- Keep an audit log of who changed which flag and when.
- Never use flags to store secrets or complex configuration.
Feature flag tools
Options include LaunchDarkly, Unleash and Flagsmith (both available open source), GrowthBook for experimentation, ConfigCat, Statsig, Firebase Remote Config for mobile apps and AWS AppConfig. OpenFeature, a Cloud Native Computing Foundation project, defines a vendor-neutral API so application code is not tied to one provider. Nexzem adds feature flags to client projects early, with naming conventions and cleanup built into the definition of done.