What a feature flag is
A feature flag (also called a feature toggle) is a switch in your code that decides whether a piece of functionality runs or not. The decision happens at runtime, so you can change behaviour without shipping a new build. You wrap a feature in a condition, and a configuration value, often managed outside the code, says whether that condition is true.
This separates two things that are usually glued together: deploying code and releasing a feature. The code can sit in production for weeks, switched off, until you decide it is ready for users.
In plain words
A feature flag works like the light switch in a room. The wiring is already in the wall, but the light only comes on when you flip the switch. You can wire up the whole room ahead of time and turn rooms on one by one, instead of rebuilding the wiring every time you want light somewhere new.
What feature flags are good for
- Gradual rollout. Turn a new feature on for 1% of users, watch the metrics and error rates, then widen to 10%, 50%, and finally everyone. If something breaks, only a small group is affected.
- A/B testing. Show version A to half your users and version B to the other half, then compare which one performs better. The flag decides who sees what.
- Kill switch. When a feature misbehaves in production, flip the flag off in seconds. No emergency deploy, no rollback, no waiting for a pipeline to finish.
- Decoupling deploy from release. Teams can merge unfinished work behind a flag and keep shipping small changes, instead of holding code in a long-lived branch.
- Access control. Open a feature to internal testers, beta users, or a single paying customer who needs it early.
Best practices and pitfalls
- Treat flags as temporary. A rollout flag has one job. Once the feature is fully live, remove the flag and the dead code behind it. Flags that linger turn into hidden complexity nobody dares to touch.
- Name them clearly.
checkout-new-payment-flowtells you what it does and when it can go.flag_v2_temptells you nothing six months later. - Watch the combinations. Every flag doubles the number of possible states your system can be in. Ten independent flags mean over a thousand combinations, and you cannot test all of them. Keep the count low and the logic simple.
- Keep config and code in sync. A flag referenced in code but missing from your config, or the other way round, is a silent bug waiting to happen. Decide what the default is when a flag is unknown.
- Do not hide permanent logic behind flags. A flag that controls a paid plan versus a free plan is not a toggle you will remove; that is business logic and belongs in your domain model, not in a rollout tool.
For anything beyond a handful of toggles, teams reach for a dedicated service such as LaunchDarkly, Unleash, Flagsmith, or PostHog, which add targeting rules, audit logs, and a UI so non-developers can flip a flag safely.
Related articles:
- What is CI/CD? - How teams build, test, and ship code automatically, so small changes reach users quickly and safely.
- What is Semantic Versioning (SemVer)? - The version-numbering rules that tell you, at a glance, how risky an update is.
Want to stay one step ahead?
Don't miss our best insights. No spam, just practical analyses, invitations to exclusive events, and podcast summaries delivered straight to your inbox.