A feature flag is a switch in software that decides whether a feature, or a version of it, is available and to whom, without anyone changing the code. Both versions go live and the flag decides which one people see. If something misbehaves, it can often be switched off in seconds.
Flags separate putting a change live from releasing it to people. A team can deploy new work, test it with colleagues and decide later when, or whether, everyone else gets it. Flickr’s engineers described the approach in 2009, and it’s now routine in software development.
Most flags do one of four jobs: hiding unfinished work until launch, showing different versions to different groups (as in A/B testing), letting a team switch off a failing feature or giving certain users access that others don’t have. Launch flags should be short-lived; access flags can last for years.
Why it matters for content
Every feature behind a flag has content behind it too: labels, error messages, onboarding, help articles, release notes and support scripts. That content needs to be ready before the flag is switched on, which often means writing for something most people can’t see yet. Help pages may need to describe both states or sit behind the same flag, so people without the feature aren’t sent looking for a button they don’t have.
Writers and reviewers also need a way to preview each variant in context. Content in an experiment needs the same review as anything else, because one group of real users will read the version that loses. Turning a feature off needs content too, such as an explanation or an alternative route, rather than a button that silently vanishes.
Content teams use flags directly as well, for seasonal guidance, regional information or trial wording, without creating unmanaged duplicate pages.
Flag debt is the cost of flags nobody removes. Each one adds states that need testing, and old ones can hide content that nobody checks or maintains. Every flag needs an owner, a reason and a removal date.
How AI changes the picture
AI features suit controlled release because their behaviour can be hard to predict. Teams can expose a new assistant, prompt or knowledge source to a small group, watch for failures and widen access carefully. A flag also gives a fast way to switch off an assistant that starts giving bad answers.
Flags can compare different instructions, models or retrieval sources. The experiment still needs ethical limits, clear measures and protection against giving one group a materially poorer or riskier service, especially where the answers affect money, health or legal rights.
AI can help analyse feedback from flagged variants, but people must decide what counts as success and when a feature is safe to release to everyone.
Questions people ask
- Do feature flags always involve an experiment?
No. Experiments are one use. Many flags exist for release control, permissions or emergency shut-off, with no comparison involved.
- Can flags replace separate pages?
Sometimes. They work well where content shares a source and changes by a defined condition, such as region or date. Distinct user needs may still call for distinct content.
- Who should control the flag?
A named owner with enough product, content and operational context to understand the consequences of switching it. For flags that change what people read, that should include someone responsible for the content.
- When should a flag be removed?
When the feature is fully launched, abandoned or no longer needs conditional behaviour. Temporary flags should have review dates, and removing the flag should include removing the content for the state that’s gone.
Learn more
- Feature Toggles – Pete Hodgson’s taxonomy of release, experiment, operational and permissioning toggles.
- Flipping Out – Ross Harmes on how Flickr used feature flags and per-user “flippers” in 2009 to deploy from a single branch several times a day, and the clean-up each launch left behind.
- Knight Capital Americas LLC – the US Securities and Exchange Commission’s 2013 order on the firm’s 2012 trading incident, describing how a repurposed flag triggered old code on a server that had missed a deployment.