For most of software history, deploying code and releasing a feature were the same event — risky, all-or-nothing, and hard to undo. Feature flags break that link, letting you put code into production but decide separately, and instantly, who sees it. It is a small idea with outsized impact on how safely teams ship.
Decoupling deploy from release
A feature flag is a conditional that wraps new behaviour: if the flag is on, the new code runs; if off, the old path does. Because the flag is controlled at runtime, not build time, you can deploy code with a feature switched off, then turn it on later for whoever you choose — without another deployment. Deploying becomes routine and low-risk, and releasing becomes a business decision rather than an engineering event.
What flags unlock
- Gradual rollouts — enable a feature for 1% of users, then 10%, then everyone, watching for problems.
- Kill switches — if something breaks, flip the flag off instantly instead of scrambling to roll back a deploy.
- A/B testing — show different variants to different users and measure which performs better.
- Trunk-based development — merge unfinished work safely behind an off flag, avoiding long-lived branches.
Testing in production, safely
Feature flags make the once-taboo idea of testing in production safe and ordinary. You can enable a new feature for just your own team or internal users, exercise it against real data and real traffic, and only widen access once you are confident. If anything looks wrong, the flag goes off and no user is affected.
Keeping flags manageable
The discipline that makes flags sustainable is cleanup. Each flag adds a branch in your code and your testing burden, so treat temporary rollout flags as temporary: once a feature is fully live, delete the flag and the old path. Distinguish these short-lived release flags from long-lived operational switches (like kill switches), which are meant to stay. Without this hygiene, a codebase drowns in stale flags nobody dares remove.
- Feature flags decouple deploying code from releasing features.
- They enable gradual rollouts, instant kill switches and A/B tests.
- They make testing in production safe by limiting who sees new behaviour.
- Remove temporary flags after rollout to avoid accumulating flag debt.
Frequently asked questions
Do feature flags slow down my code?
The runtime cost of a flag check is negligible. The real cost is complexity in the codebase, which is why removing stale flags matters.
What is a kill switch?
A feature flag kept specifically to disable a feature instantly in an emergency, without needing a deployment or rollback.