Feature flags
Also known as: feature toggles, feature switches, feature flagging
Feature flags, also called feature toggles, are switches in software that turn a feature on or off without deploying new code.
Teams use them to release to a small group first, run experiments, or switch off a broken feature in seconds. While flags make releases far safer, every flag is also a little piece of debt: forgotten flags pile up and make code harder to reason about.
Feature flags, explained at three levels
At home
Think of a light switch wired to a new room in your house. The wiring is all installed, but the light stays off until someone flips the switch, and it can be switched off again instantly. A feature flag works the same way: the new feature's code is already inside the app, but a setting decides whether anyone sees it, and that setting can change without updating the app.
At work
Feature flags are switches in software that turn a feature on or off without releasing new code. That separates deploying code from releasing a feature: code reaches production quietly, then the feature is enabled for staff, then a small share of customers, then everyone. Businesses care because launches become gradual and reversible, and a broken feature can be switched off in seconds instead of hours.
At home
Inside the app, a flag is just a question in the code: is this feature on for this person? The answer comes from targeting rules stored in a flag service. Rules can say 'on for beta testers,' 'on for users in Canada,' or 'on for a random 5% of visitors.' The app checks those rules each time, which is why two people using the same app can see different versions at once.
At work
A flag system has three parts: a management console where staff create flags and targeting rules, a service that distributes those rules, and SDKs inside each application that evaluate them. Flags come in types with different lifespans: release flags for gradual rollouts, experiment flags for A/B tests, operational kill switches for shedding load, and permission flags for plan tiers. Tools include LaunchDarkly, Unleash, and Flagsmith, with OpenFeature offering a vendor-neutral API.
At home
Every flag doubles the number of ways the code can behave. Ten independent flags create 1,024 possible combinations, and nobody tests all of them. Old flags also leave dead branches of code that still look live. While flags make each release safer, in my opinion short-lived flags should be treated as temporary scaffolding, created with an expiry date and a ticket to remove them once the rollout finishes.
At work
For speed and resilience, SDKs usually cache flag rules and evaluate them locally, streaming updates from the flag service, so an outage there leaves the app running on its last known rules or safe defaults. Flag changes are production changes: Knight Capital's 2012 loss came partly from a repurposed flag. Mature setups log every change with its author, require approval for critical flags, and automate stale-flag detection. OpenFeature reduces lock-in by standardizing the evaluation API across vendors.
Real-world examples
At home
Aisha noticed her banking app had a new budgeting tab while her partner's didn't. The bank was testing it with a small group of customers using a feature flag before turning it on for everyone.
At work
Jerome manages releases for a Canadian e-commerce site. During a Black Friday traffic spike, a new recommendation widget slowed checkout. His team flipped its kill switch, and checkout recovered in seconds, with no emergency deployment.
How it compares
| feature | Feature flags | Code deployment |
|---|---|---|
| What changes | Who sees a feature | What code is running |
| Speed to undo | Seconds | Minutes to hours |
| Targeting | Specific users or groups | Usually all users |
| Main risk | Flag debt and hidden complexity | Big-bang failures |
Flags turn risky launches into gradual, reversible ones.
For analysts
Feature flags give product managers real control over launches, not just engineers. I'd insist on an owner and a removal date for every flag, because the cost of flags shows up months later as confusing bugs.
History & origin
Developers have used configuration switches for decades, but feature flags became a named practice in the late 2000s. Flickr's 2009 talk '10+ Deploys Per Day,' by John Allspaw and Paul Hammond, described flags as key to shipping continuously, and Martin Fowler's writing on 'feature toggles' spread the idea. The risks became famous in 2012, when Knight Capital lost about US$440 million in 45 minutes after a deployment reactivated old code tied to a repurposed flag. LaunchDarkly, founded in 2014, built a business around flag management, and the vendor-neutral OpenFeature standard joined the Cloud Native Computing Foundation in 2022. In my view, Knight Capital is the best argument for both flags and flag hygiene.