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
A feature flag is like a light switch for part of an app. The new feature is already installed, but it stays off until someone flips the switch, and it can be switched off again instantly if something goes wrong.
At work
Feature flags let teams separate 'deploying code' from 'releasing a feature.' Code can go to production quietly, then be turned on for staff, then a small share of customers, and finally everyone.
At home
Flags can target specific people: only beta testers, only users in Canada, or a random 5% of visitors. That's why two people using the same app can see different versions of it at the same time.
At work
Common flag types include release flags (short-lived, for gradual rollouts), experiment flags (for A/B tests), operational 'kill switches' (to disable costly features under load), and permission flags (for plan tiers). Each type needs a different lifespan and owner.
At home
Every flag doubles the number of ways the code can behave. Ten independent flags mean over a thousand combinations. In my opinion, that's why short-lived flags should come with an expiry date and a ticket to remove them.
At work
At scale, flag systems need fast local evaluation (so a flag service outage doesn't break the app), audit logs for who changed what, safe defaults, and cleanup automation. Treat flag changes as production changes: a flipped flag can cause an outage as surely as a bad deployment. Standards such as OpenFeature reduce vendor lock-in.
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.