Feature flags: turning things on for some users first
How software ships new features switched off, turns them on for a few people, and rolls back with a switch instead of a deploy.
The short answer
A feature flag is a switch inside the software that decides, per user, group or percentage, whether a feature is visible or active. Code for a new feature ships to production switched off. Internal users turn it on for themselves and test it on the real system. A small share of customers gets it next, with monitoring watched. Then everyone. If anything misbehaves, it is switched off in seconds, for everyone, without a deploy. Flags separate the technical act of deploying from the business decision of releasing, and they turn risky launches into gradual, reversible ones. They also need housekeeping: an owner and an expiry per flag, and removal when done.
What flags make possible
| Use | How | Benefit |
|---|---|---|
| Dark launches | Ship the code off; assemble the feature over several small merges | Small, safe deploys; no long-lived branches |
| Internal testing on production | On for staff only | Real data, real integrations, no risk to customers |
| Gradual rollout | On for a percentage, increasing | Problems affect few; monitoring by cohort |
| Kill switch | Off in seconds when something goes wrong | Recovery without a deploy or rollback |
| Per-customer features | On for specific accounts or plans | Pilots, early access, tiered products |
| Experiments | Two variants, measured | Decisions from data rather than opinion |
| Safe dependencies | A flag around each third-party integration | Switch off a failing vendor call without touching code |
Using them well
- Flag anything risky, large or customer-visible; do not flag trivial changes.
- Name each flag clearly, with an owner and an expected removal date.
- Test both states in the pipeline while the flag exists.
- Roll out in steps: staff, a small percentage, a larger one, everyone, watching errors and business signals by cohort.
- Keep kill switches on integrations and risky features permanently, documented.
- Remove the flag once fully on or abandoned; the removal is a story like any other.
- Review the flag list monthly; anything past its date is cleaned up.
What you notice
Features arrive for you and a few colleagues first, on the real system, before customers see them. Launches become non-events: a switch flipped after a week of watching, rather than a deploy everyone braces for. When something new misbehaves, it disappears in seconds while the rest keeps working. And a pilot for one customer or one plan is a configuration, not a project.
What this means for you
Expect new features to ship switched off, be tested by your own people on the real system, roll out gradually with monitoring, and be switchable off in seconds. Expect a short, owned list of flags that is cleaned up monthly. It is how software launches stop being events and how a bad release becomes a switch rather than an outage.
Frequently asked questions
Why ship code that is switched off?
Because merging small pieces continuously is safer than merging one large piece at the end, and a flag lets the pieces be in production without being visible. The feature is assembled behind the switch, tested by internal users on the real system, and turned on for everyone when it is complete. The deploy risk is spread across many small steps; the release is a business decision made when ready.
Can we turn a feature off quickly if something goes wrong?
That is one of the main reasons for flags. If a newly released feature misbehaves, it is switched off in seconds for everyone, without a deploy or a rollback, and the rest of the application continues. Kill switches on risky features, integrations and third-party calls are a standard safety measure.
Do flags make the software more complicated?
Temporarily, per flag, and permanently if they are not cleaned up. Every flag is a branch in the code that must be tested both ways. The discipline is an owner and an expiry per flag, and removal once the feature is fully on or abandoned. A codebase with hundreds of forgotten flags is the failure mode; a handful of live, owned ones is the practice working.