Feature flags (also called feature toggles or feature switches) are a software development technique that lets you enable or disable functionality in your application at runtime without deploying new code. They decouple code deployment from feature release, giving teams fine-grained control over who sees what and when.
A feature flag is essentially a conditional check in your code — an if/else branch — whose condition is controlled by an external configuration value rather than a hardcoded constant. When the flag is 'on', users see the new behavior; when it's 'off', they see the old behavior. This configuration can live in a database, a config file, an environment variable, or a dedicated feature-flag management platform like LaunchDarkly, Flagsmith, or Unleash.
They allow teams to merge unfinished code into the main branch behind a flag, eliminating long-lived feature branches and the painful merge conflicts they produce. Product teams can perform gradual rollouts, canary releases, or A/B tests by targeting specific user segments — such as internal employees, beta users, or a percentage of traffic. In a production incident, a flag lets you instantly kill a bad feature without a hotfix deployment, dramatically reducing mean time to recovery (MTTR).
At the core, your application calls a flag evaluation function — e.g., featureFlags.isEnabled('new-checkout', user) — which returns a boolean or a variant value. The flag service evaluates targeting rules (user ID, region, plan tier, random percentage bucket) against the flag's configuration and returns the result, typically in milliseconds. Most SDKs cache flag state locally and stream updates in real time so evaluation adds negligible latency to requests.
Release flags are short-lived toggles that gate unfinished features during development and are removed once the feature is fully rolled out. Experiment flags (A/B flags) run controlled experiments to measure the impact of a change on key metrics. Ops flags are long-lived killswitches for performance-sensitive features like rate limiting or circuit breakers. Permission flags enable or disable functionality based on a user's subscription tier or role, and can live indefinitely in the codebase.
The most common pitfall is accumulating stale flags — code paths guarded by flags that were never removed after a full rollout, sometimes called 'flag debt'. Over time this makes the codebase harder to reason about and test, because the number of possible code-path combinations grows exponentially with each active flag. Establish a policy for every flag: set a planned removal date, track flags in your issue tracker, and make cleanup a first-class engineering task just like any other technical debt.
Keep flag evaluation logic out of deep business logic; evaluate flags at the boundary of your system (controllers, service entry points) and pass plain values inward so core logic stays testable without a flag SDK. Use consistent naming conventions — e.g., enable_new_checkout_flow — and document the purpose and expected expiry of every flag in your flag management tool. Always test both the enabled and disabled paths in your automated test suite to avoid regressions when a flag is eventually removed.
© RM Full Stack & AI Engineer · All guides · Roadmaps · Open the app