Blog How feature flags change the way teams ship
How feature flags change the way teams ship
TL;DR A feature flag wraps new code in a switch, so you can deploy it turned off and release it later without another deploy. That decouples shipping code from releasing features, which enables merging unfinished work safely, gradual rollouts, instant rollback, and testing in production, with the cost of flags you must clean up.
A feature flag is a simple thing, a switch that turns code on or off without a deploy, but it changes how a team ships in ways that go well beyond the switch itself. The core idea is decoupling: shipping code and releasing a feature stop being the same event.
The one idea: decouple deploy from release
Normally, deploying code is releasing it. Merge, deploy, and the feature is live for everyone at once. That ties every release to a deploy and makes each one a bigger, riskier event.
A feature flag breaks that link. You wrap the new feature in a switch, deploy it turned off, and release it later by flipping the flag, no second deploy required. Now the code being in production and the feature being live are two separate decisions.
What that enables
Once shipping and releasing are separate, a lot of good practices open up.
- Merge unfinished work safely. Incomplete features live behind an off flag on the main branch, so you avoid long-lived branches and the painful merges they cause.
- Roll out gradually. Turn a feature on for one percent of users, then ten, then everyone, watching for problems as you go instead of exposing everyone at once.
- Roll back instantly. If something misbehaves, flip the flag off. No emergency deploy, just a switch.
- Test in production. Enable a feature for your team or a test cohort against real traffic and data before anyone else sees it.
The team ends up shipping smaller changes more often, with less risk riding on each one.
The cost: flags are debt
Feature flags are not free. Each one is a branch in your code, an extra path to reason about and test. Left alone, they pile up: dead conditionals, toggles no one remembers, features that shipped months ago still wrapped in a switch.
The discipline that keeps flags an asset is removing them. Once a feature is fully rolled out and stable, delete its flag and the old path. A flag is meant to be temporary scaffolding, not permanent structure.
The shift
Adopting feature flags is less a tooling change than a change in how the team thinks about releasing. Deploys become frequent and boring; releases become gradual and reversible; risk gets spread thin instead of concentrated. Used with the discipline to clean up after themselves, they let a team move faster precisely because each individual move is smaller and safer.
FAQ
What is a feature flag?
It is a switch in your code that turns a feature on or off without deploying again. You wrap the new behaviour in a condition tied to the flag, deploy with it off, and flip it on when you are ready. Deploying the code and releasing the feature become separate acts.
How do feature flags help teams?
They let you merge unfinished work safely behind an off flag, roll a feature out gradually to a fraction of users, turn it off instantly if it misbehaves, and test in production with real traffic. The team ships smaller and more often, with less risk per release.
What is the downside of feature flags?
Flags accumulate. Each one is a branch in your code, and if you never remove them, the codebase fills with dead conditionals and stale toggles. The discipline is to delete a flag once its feature is fully rolled out and stable.