What Is a Feature Flag?
A feature flag, also called a feature toggle, is a conditional check in an application's code that determines whether a piece of functionality is active. Instead of controlling a feature by deploying or reverting code, developers flip the flag in a configuration system, and the change takes effect immediately for chosen users or all users. This separates deploying code from releasing a feature, letting teams ship code to production before it is publicly visible and turn problematic features off instantly without a new deployment.
A feature flag is a switch in your code that turns a feature on or off without deploying new code, making rollouts and rollbacks instant.
Deploying code and releasing a feature are usually treated as the same event, but they do not have to be. Feature flags split them apart, and that separation is the entire point.
Decoupling deployment from release
Without feature flags, shipping a new feature means finishing the code, merging it, and having it go live for every user the moment the deployment completes. If something is wrong, the only fix is another deployment, which takes time and carries its own risk.
With a feature flag wrapped around the new code, the feature can be merged and deployed to production while switched off. The code exists on the live servers, inert, until someone flips the flag. This means deployments can happen continuously, several times a day, entirely disconnected from when a feature actually becomes visible to users. A marketing launch date no longer dictates a deployment schedule; it just dictates when the flag gets flipped.
What a feature flag looks like in code
A feature flag is typically a conditional check against a configuration value:
if (featureFlags.isEnabled('new-checkout-flow', currentUser)) {
return renderNewCheckout();
} else {
return renderOldCheckout();
}The isEnabled check might look at a simple on/off value, or evaluate more complex targeting rules: is this user in the beta group, does their account belong to a specific plan tier, or are they in the 10% of users randomly selected for a gradual rollout. That evaluation logic is usually handled by the feature flag platform, while the application code just asks a yes-or-no question.
Gradual rollouts and instant kill switches
Two practical patterns account for most real-world feature flag use.
The first is a gradual, percentage-based rollout: enable a new feature for 5% of users, watch error rates and performance metrics, then increase to 25%, 50%, and 100% over hours or days if nothing goes wrong. This limits the blast radius of a bug to a small fraction of users instead of everyone at once.
The second is the kill switch: wrapping any feature, especially a new or risky one, in a flag that can be switched off instantly if it starts causing errors, timeouts, or excessive load on a downstream service. This turns an incident that would otherwise require an emergency deployment and a tense fifteen minutes of waiting for a build to finish, into a single toggle flipped in seconds.
Feature flags for A/B testing
Because a flag can show different logic to different user segments, the same mechanism used for gradual rollouts naturally supports A/B testing: show variant A of a checkout flow to half the users and variant B to the other half, then compare conversion rates. The flag decides which code path a given user hits; analytics tooling measures the outcome.
The maintenance cost: remove flags you no longer need
The failure mode of feature flags is accumulation. Every flag added and never removed leaves a permanent branch of conditional logic in the codebase, and after a year of active development a project can end up with dozens of flags nobody remembers the purpose of, some referencing features that were fully launched months ago. Treat a flag as temporary scaffolding: once a feature has been fully rolled out and the decision to keep it is final, remove the flag and the old code path in the same pull request that confirms the rollout succeeded.
Our tip: Before adding a feature flag system, write down who is allowed to flip which flags and where that decision gets recorded. A flag with unclear ownership tends to stay in the code long after it should have been removed, quietly making the codebase harder to reason about.
Frequently asked questions
What is the difference between a feature flag and an environment variable?
An environment variable is typically set once when an application starts and requires a restart to change, making it suited for configuration that rarely changes, like a database connection string. A feature flag is designed to be toggled at runtime, often per user or per group, without restarting or redeploying anything. Feature flag systems also usually support gradual rollouts and targeting rules, which environment variables do not handle.
Can feature flags be used for something other than releasing new features?
Yes, feature flags are commonly used as kill switches for risky functionality, letting a team instantly disable a feature that is causing errors or excessive load without waiting for a new deployment. They are also used for A/B testing, showing two variants of a feature to different user segments to measure which performs better, and for permission-based access, where a feature is only visible to certain customer tiers or internal staff.
Do feature flags slow down an application?
A well-implemented feature flag check is a simple conditional lookup, typically cached in memory, and adds negligible overhead, often less than a millisecond. The bigger risk is not performance but code complexity: leaving old flags in the codebase after a feature has fully launched creates dead branches of logic that make the code harder to read and maintain. Removing flags once a decision is final is as important as adding them.
Do I need a dedicated feature flag service, or can I build this myself?
For a small number of flags, a simple configuration object or database table checked by your application is enough and requires no extra service. Dedicated platforms like LaunchDarkly, Flagsmith, or Cloudflare's feature flag tooling become worthwhile once you need percentage-based rollouts, user targeting rules, or a dashboard non-developers can use to toggle features without touching code.