On this page
What Is a Feature Flag?
Feature flags let you ship dark and enable later. But there are 4 types — release, experiment, ops kill-switches, and permission gates — and mixing them up creates tech debt.
Quick answer
- A feature flag is a switch in code that turns behavior on or off at runtime, without a redeploy.
- Flags decouple deploying code from releasing the feature, enabling gradual rollouts and instant kill switches.
- Flags create technical debt if they are never cleaned up, so each one needs an owner and an expiry.
What is a feature flag?
A feature flag (or toggle) is a conditional in your code that decides at runtime whether a feature is active, controlled by configuration outside the code. If the flag is off, the new code path is dormant; flip the flag, and it’s live. This separates the deployment of code from the release of a feature, which used to be the same event.
How does it work?
The simplest form is a configuration check:
if (flags.isEnabled("new-checkout")) {
return newCheckout(req);
}
return oldCheckout(req);Real flag systems manage the flags centrally, allowing you to target them by percentage, user segment, or environment, and to change them without touching code. That targeting is what enables staged rollouts and instant rollback.
Why does it matter?
Flags let you ship code continuously while controlling when users see it. You can test in production behind a flag, roll a feature out to 1% and expand, and disable a misbehaving feature in seconds. A flag is also a clean “kill switch” for a feature that’s causing trouble — the same idea that pairs with canary deployments.
Where this bites vibecoders
AI assistants rarely add flags on their own; they generate the feature fully wired in. The result is a release model with no brake pedal: a bad feature is live for everyone the moment it’s merged. A single flag on a risky change is often the cheapest insurance a solo builder can buy.
Where AI coding assistants get this wrong
- Hardcoding feature switches as booleans in code, requiring redeploys to change.
- Generating flag logic with no default or fallback, crashing when the flag service is unreachable.
- Leaving flags in place forever, so the codebase fills with dead branches.
- Confusing flags with configuration, scattering toggles instead of centralizing them.
Checklist
- Wrap risky changes in a flag before merging.
- Make flags fail safe: default to the old behavior if the flag can’t be read.
- Target flags by percentage or segment for gradual rollouts.
- Give every flag an owner and an expiry date.
- Remove flags once a feature is stable, and the branches with them.
FAQ
What is the difference between a feature flag and a canary?
A canary shifts traffic between deployed versions of a service; a feature flag toggles behavior inside one version for selected users. You can canary a new service and flag a new feature within it. See What Is a Canary Deployment?.
What is a kill switch?
A kill switch is a flag you flip to disable a feature instantly during an incident, without deploying a rollback. It’s the emergency-brake use of feature flags and one of their biggest operational benefits.
Why do flags become debt?
Each flag is a branch in code, and old flags leave dead paths and confusing logic. Without an owner and an expiry, flags accumulate and complicate the codebase — which is why cleanup is part of the practice, not an afterthought.
Related topics
- Feature Flags vs Feature Toggles: What’s the Difference?
- What Is a Canary Deployment?
- What Is CI/CD?
- What Is the Twelve-Factor App Methodology?