What is a feature flag?

A feature flag is a conditional switch in the code that decides, at runtime, whether a feature is active, without requiring a new deploy to change the answer. Technically it is little more than an if reading a value from a configuration system external to the compiled code, but the practical effect runs deep: it separates the moment code reaches production (deploy) from the moment users see it (release). A team can ship an incomplete feature to production behind a flag that is off, merge it into the main branch with no risk, and then turn it on for a single user, for 1% of traffic, or for everyone, through an instant and reversible configuration change. Pete Hodgson, in what became the most widely cited reference on the topic, describes it as the tool that makes trunk-based development on unfinished code possible: no more isolated branches diverging for weeks, because the new code already lives on the main branch, simply disabled.

The toggle taxonomy and the deploy/release split

Hodgson distinguishes four families. Release toggles hide an incomplete feature until it is ready for the public, and are inherently temporary. Experiment toggles route different users toward different variants to measure the effect, the routing an A/B test rests on, which still needs its own experimental design. Ops toggles are operational switches, often a "kill switch" to disable a heavy or unstable feature in an emergency without rolling back the deploy. Permission toggles activate a feature for specific user segments, for example an enterprise plan or a beta program. What unites them is the deploy/release split: the first is a technical event, the second a product decision, and the feature flag is what lets them happen at different times, with whoever decides the release not necessarily the same person who pushes the deploy.

An enterprise example

A bank rebuilding its online banking platform merges its new payments module into the main branch weeks in advance, behind a permission toggle exposing it to the internal QA team only. On release day the release toggle switches to dynamic routing and turns it on for 0.5% of customers, monitors errors for an hour, then rolls up to 5%, 50%, 100%, always through configuration and never through a new deploy. If an issue surfaces mid-rollout, an ops toggle disables it in seconds, not in the time a full infrastructure rollback would take during peak hours.

Why it matters for decision-makers

The risk feature flags introduce is systematically underestimated: every release or experiment toggle never removed past its expiry is dead code that doubles the paths that need testing, one for each state of the switch, and the combinatorics of several active flags together grow faster than anyone can hold in mind. It is technical debt in one of its most insidious forms, because it does not fail to compile and does not fail a test: it accumulates silently until nobody remembers what a flag is for, and nobody dares turn it off. The discipline that separates an organization that uses feature flags well from one that chokes on them is not the ability to create them, but the rigor of removing them: a flag lifecycle plan with an expiration date declared at creation, an owner for every live flag, and a periodic audit that retires expired temporary toggles, distinguishing them from permission and ops toggles that are permanent by design.