What Is a Feature Flag, and Why Do Teams Use Them?

A feature flag is a conditional check in your code — usually little more than an if-statement — that decides whether a piece of functionality is active, without requiring a new deployment to turn it on or off. Instead of shipping a feature by deploying code that runs it unconditionally, you deploy the code behind a flag, and control whether it's live through a separate configuration change that takes effect immediately, often without touching the application's build or deployment pipeline at all.

The problem feature flags actually solve

Without flags, "shipping a feature" and "deploying code" are the same event — the moment the deployment finishes, every user sees the new behaviour, and rolling it back means a new deployment (or a revert-and-redeploy) rather than a quick toggle. This creates real friction in a few common, specific situations: a feature that's only ready for internal testing but whose code needs to merge to the main branch to avoid a painful long-lived branch; a risky change a team wants to enable for 5% of users before a full rollout; a feature tied to a specific announcement date that shouldn't go live the moment the code merges; or an emergency where a newly-deployed feature is causing problems and needs to be turned off immediately, faster than a rollback deployment would take. Feature flags decouple "the code is deployed" from "the feature is live," which is the single idea underneath every use case below.

The simplest form: a flag in configuration

At its most basic, a feature flag is a boolean read from a config file, environment variable, or a simple database row: `if (flags.newCheckoutFlow) { ... }`. Flipping the flag doesn't require a new deployment — it requires updating that one configuration value, which typically takes effect within seconds to minutes depending on how the application reads it (on every request, versus cached and refreshed periodically). This simple version already delivers most of the core benefit: separating when code ships from when a feature is visible.

Beyond on/off: percentage rollouts and targeting

Real feature-flag systems go well beyond a global boolean. A percentage rollout activates a feature for a defined, consistent percentage of users (5%, then 25%, then 100%) rather than everyone at once, letting a team watch real production metrics and error rates on a small population before committing to full exposure. User targeting activates a feature only for specific segments — internal employees, users in a particular country, users on a specific subscription tier, or a manually curated beta-tester list — which is what makes controlled internal testing and gradual external rollouts both possible from the same underlying mechanism. Consistent hashing (typically based on a stable user ID) ensures the same user keeps seeing the same flag state across sessions during a percentage rollout, rather than randomly flickering between old and new behaviour on each visit.

Kill switches — the emergency-response use case

A kill switch is a feature flag specifically kept ready to instantly disable a feature that's causing a production problem — a payment integration behaving unexpectedly, a new algorithm producing bad results, a third-party API a new feature depends on going down. Because flipping a flag is typically near-instant and doesn't require a new deployment, it's meaningfully faster than a rollback deployment during an actual incident, when minutes matter. Teams that deliberately wrap risky new functionality in a flag from day one — even when they don't expect to need the kill switch — are making a specific bet that the ability to instantly disable something is worth the small added complexity of checking a flag, and for genuinely risky changes, that bet consistently pays off.

Feature flags vs A/B testing — related, but not the same thing

The two overlap in mechanism (both often use percentage-based user bucketing) but differ in purpose. A feature flag is primarily about controlling exposure and risk — is this feature on, and for whom. An A/B test is about measuring a specific effect — does variant B produce a statistically meaningful improvement over variant A on some metric, deliberately keeping both variants running long enough to gather that comparison. Many A/B tests are implemented using the same flagging infrastructure, since "which variant does this user see" is structurally the same problem as "is this feature on for this user" — but a feature flag's simplest use case (a rollout toggle with no comparison being measured) doesn't require the statistical rigor an actual A/B test does.

Trunk-based development and long-lived branches

Feature flags are also a core enabler of trunk-based development — a workflow where developers merge to the main branch frequently, even for incomplete work, rather than maintaining long-lived feature branches that diverge further from main every day they exist. Code for an in-progress feature merges behind a flag that's off by default, meaning it exists in the codebase and gets tested against everyone else's changes immediately, without being visible or active for real users. This avoids the classic long-branch problem — a painful, conflict-heavy merge once the branch is "finally ready" — by making "exists in the codebase" and "is active for users" two separately controlled states from the very first commit.

The real cost: flag debt

Feature flags aren't free — every flag is a branch point in the code that has to be reasoned about, tested (ideally in both states), and eventually removed once its purpose is served. A flag that stays in the codebase long after a feature has fully rolled out (or been fully abandoned) becomes "flag debt": dead conditional logic, an extra code path nobody's actively thinking about, and a growing source of confusion for anyone reading the code later without knowing the flag's current real-world state. Mature feature-flag practice treats flag removal as part of the feature's actual definition of done, not an optional cleanup task — a rollout isn't finished until the flag and the old code path it protected are both gone, leaving just the new behaviour as the only path.

Different categories of flags, by how long they live

Not all feature flags serve the same purpose, and conflating them is a common source of confusion about when a flag should be removed. A release flag is short-lived by design — it exists only to control a rollout, and should be deleted once the feature is fully live for everyone. An experiment flag (used for A/B testing) lives exactly as long as the experiment needs to run to reach statistical significance, then gets resolved one way and removed. An ops flag (like a kill switch for a specific integration) can legitimately live much longer, sometimes permanently, since its whole purpose is standing readiness for an emergency that may never come. A permission flag (gating a feature by subscription tier or user role) is often permanent by design, since it's really an access-control mechanism dressed up as a flag rather than a temporary rollout control. Treating all four the same — and specifically assuming every flag should eventually be deleted — is how the ops and permission categories get miscategorised as forgotten cleanup debt, when their long life is actually correct.

Testing implications

A codebase with active feature flags technically has more possible states than one without — a feature being on for one test run and off for another means the same code path isn't always being exercised the same way. Thorough testing practice accounts for this by explicitly testing both flag states for anything actively rolling out, rather than only testing whatever the default happens to be in the test environment. This matters more than it sounds: a bug that only manifests in the "off" state (the code path most of the team stops thinking about once the "on" state looks good) can sit undiscovered through an entire rollout, only surfacing when something forces a rollback to the off state under real production pressure — precisely the worst possible moment to discover a second bug.

Common feature-flag systems

• LaunchDarkly, Split, and Flagsmith — dedicated, managed feature-flag platforms with percentage rollouts, targeting rules, and analytics built in.
• Unleash — a popular open-source feature-flag system that can be self-hosted.
• Cloud-provider-native options — AWS AppConfig, and equivalents from other major clouds, for teams already committed to that ecosystem.
• A simple in-house implementation — a config table or environment variables — which is often genuinely sufficient for a small team's early needs, before the targeting/percentage-rollout complexity of a dedicated platform is actually worth adopting.

Feature flags and CI/CD

Continuous deployment — automatically shipping every merged commit to production — sounds risky without a safety valve, and feature flags are frequently that valve. A team practicing continuous deployment can merge and auto-deploy code constantly while keeping genuinely new user-facing behaviour behind a flag, decoupling "this code is now running in production" (which happens continuously, many times a day) from "users can now see this feature" (which happens deliberately, on the team's own schedule). This combination — ship constantly, expose deliberately — is a large part of what makes aggressive continuous-deployment practices feel safe enough to adopt at all, since the riskiest part of shipping (making new behaviour visible to real users) stays under separate, fine-grained control even as the underlying deployment pipeline runs on a fast, fully automated cadence.

When a feature flag is overkill

Not every piece of new functionality needs to be flagged. A low-risk, fully-tested change with no reason to roll it back gradually doesn't benefit much from the added complexity of a flag — it just adds an extra conditional and a future cleanup task with no real corresponding benefit. Flags earn their cost specifically for genuinely risky changes, changes that need gradual exposure, changes tied to external timing, or changes a team wants a fast kill switch for — reaching for a flag on every single change, out of general caution, mostly just accumulates flag debt faster than it prevents real incidents.

Who owns a flag, and for how long

A practice worth adopting alongside any feature-flagging system is explicit flag ownership and an expiry expectation set at creation time — who's responsible for this flag, and roughly when should it be fully rolled out and removed. Without this, flags tend to accumulate as an organisation grows, since creating a new flag is easy and low-friction while removing one requires someone to actively notice it's no longer needed, confirm it's safe to delete, and do the (often unglamorous) work of removing the conditional and the now-dead code path it protected. Some teams enforce this with tooling — a flag-management platform that flags (no pun intended) any toggle that's been at 100% or 0% for some threshold period as a candidate for removal — but even a lightweight convention of naming an owner and a target removal date at creation time meaningfully reduces how much flag debt accumulates over a codebase's life.

A quick mental model to decide if you need one

Before adding a flag, it's worth asking a short, specific set of questions rather than defaulting to "flags are good practice, add one." Does this change need to reach users gradually rather than all at once? Is there a real, plausible scenario where this needs to be disabled quickly without a redeploy? Does the timing of visibility need to be decoupled from the timing of the code shipping (an announcement date, a coordinated launch)? If the honest answer to all three is no, a flag adds overhead — a branch to maintain, a future cleanup task — without a corresponding benefit, and the change is better shipped as ordinary code. If any answer is genuinely yes, the flag is very likely worth its cost, and the earlier questions about ownership and expiry become the things to get right from the start rather than an afterthought.

Common mistakes with feature flags

• Never removing a flag after a feature has fully rolled out, leaving permanent dead code and confusion about which path is actually live.
• Nesting many flags together until the actual active code path for a given user becomes hard to reason about without checking several flag states at once.
• Not testing both states of a flag (on and off) before merging, so the "off" path — which might stay live for weeks during a gradual rollout — has an undiscovered bug.
• Using a feature flag as a substitute for proper access control or security — a flag hiding a feature from the UI doesn't actually prevent a determined user from hitting the underlying API directly if it isn't separately secured.
• Treating a percentage rollout as "done" the moment it reaches 100%, without actually removing the flag and old code path afterward.