What is a feature flag?
A feature flag, also called a feature toggle, is a piece of configuration that lets a team turn a feature on or off, or expose it to a specific subset of users, without deploying new code. Engineering ships the feature behind the flag as part of a normal release; product and growth teams then decide who sees it and when.
Why feature flags exist
Before feature flags became standard practice, shipping a feature meant it went live for everyone the moment the deploy finished. That made rollbacks painful and made gradual testing nearly impossible without maintaining separate branches or environments. A feature flag turns "is this feature live" from a deployment question into a configuration question.
What feature flags make possible
Gradual rollouts: releasing a feature to 5% of users, then 25%, then 100%, watching for problems at each step.
A/B testing: running two versions of a feature behind different flags to compare outcomes, feeding directly into A/B testing programs.
Beta access: exposing a feature to a specific segment, such as design partners or a particular plan tier, before a general release.
Instant rollback: turning a feature off immediately if something breaks, without an emergency deploy.
What a feature flag doesn't solve
The flag controls exposure, not comprehension. Turning a feature on for a segment of users doesn't mean those users will notice it, understand what it does, or know how to use it well. That's a separate problem, solved with feature discovery and in-app guidance layered on top of the flagged release.
Coordinating flags with in-app guidance
A feature exposed to 25% of users pairs naturally with a hotspot or tooltip scoped to that same 25%, so the people who can see the feature are also the people being told it exists, rather than discovering it by accident or missing it entirely.
