Feature Flag Management

Definition

Feature flag management is the practice of wrapping new functionality in runtime toggles so that its visibility is controlled by configuration, not by deployment. A flag can be enabled for internal users only, for a percentage of production traffic, for a specific customer segment, or globally. Managed properly, flags separate the technical act of deploying code from the business act of releasing a feature — and give teams a same-second rollback path when something breaks.

Why It Matters

Deployments used to be the release. Every push to production was a bet, every rollback was a re-deploy, and every risky change was scheduled for a Friday evening no one wanted. Feature flags dissolve that coupling. Code ships to production continuously; features light up gradually and independently. When they misbehave, the flag flips off in seconds. When they work, the flip becomes a full launch. The engineering culture that grows around flags — small changes, fast iteration, targeted rollout — is often the real reward, more than any individual toggle.

Types of Flags

• Release flags — short-lived, wrap a new feature until it is fully launched, then removed.
• Experiment flags — split traffic for A/B tests, tied to an analytics event stream.
• Ops flags — kill switches for dependencies (disable a slow third-party call when it is failing).
• Permission flags — long-lived, gate functionality by customer plan or role.

Real-World Example

A UK fintech launched a new instant-payments capability behind a release flag. The flag was enabled for internal staff on day one, for one small merchant on day three, for 1% of traffic on day five and for 10% on day seven. On day eight, the on-call engineer noticed a 3× jump in latency on the payments path; a look at the dashboard traced it to a downstream provider that could not keep up. The flag was flipped off at 09:14 and the incident was over at 09:15 — no rollback deploy, no customer notice, no page-out. The provider fixed their capacity within 48 hours, the flag was re-enabled and the launch continued. Without the flag, the fix would have been an emergency rollback with unknown downstream effects.

How to Run It Properly

1. Every flag has an owner, a purpose and a retirement date recorded when it is created. Orphan flags are technical debt with interest.
2. Default new flags to off in production, on in development. Never ship a flag that is on by default and then rely on turning it off.
3. Roll out in stages — internal, canary customer, small percentage, larger percentage, full. Move up only after each stage is quiet.
4. Instrument the flag itself. Log evaluation counts, decisions and errors. Blind flags are worse than no flags.
5. Automate flag cleanup. A weekly report of stale flags, and an owner nominated to close them.
6. Test both sides of the flag in CI. A feature only works with the flag on is a bug waiting to be found by the on-call engineer.
7. Kill switch by design. Every risky dependency has an ops flag; every ops flag is drilled quarterly.

Practical Lessons Learned

• Flags proliferate faster than you think. A team of 30 engineers reaches 300 flags in a year without hygiene.
• Nested flags are landmines. A flag whose default depends on another flag is untestable — flatten them.
• Long-lived permission flags belong in a permission system, not in the flag store.
• Flag evaluation should be fast. A slow flag provider becomes a latency source across every request.
• Ops flags save more incidents than they cause. The rare accidental flip is worth the many deliberate ones.

Expert Tips

• Prefix flags by team — payments.instant_v2 — so ownership is obvious from the name.
• Record every flip in an audit log with the operator, timestamp and reason. Post-incident review needs this data.
• Use the same flag SDK on server and client. Diverging behaviour across tiers is a class of bugs no one enjoys.
• Retire the flag as part of "definition of done." A launched feature with its flag still in the code is not done.
• Include flag state in bug reports. "This bug reproduces when flag X is on and flag Y is off" is a specific, fixable ticket.

Common Mistakes

• Flags left in the code long after full launch, hiding dead branches.
• Default-on flags shipped to production and forgotten.
• Permission flags that grow into a shadow authorisation system.
• Untested "off" branches — regressions when the flag is disabled.
• No audit log — nobody knows who flipped what during an incident.
• Marketing announcing a feature before the flag is on for real customers.

Key Takeaways

• Feature flags separate deploy from release and give instant rollback without redeploy.
• Every flag has an owner, a purpose and a retirement date.
• Roll out in stages, instrument both sides, and retire the flag as soon as the feature is stable.
• Ops flags are cheap insurance against unreliable dependencies.
• Flag hygiene is a first-class engineering discipline, not an afterthought.

Related Concepts

Interlocks with Deployment Freeze Window, Rollback Plan, Zero-Downtime Migration and Production Readiness Review. Rollout patterns at PMMilestone.org.