Flags are product inventory, not temporary duct tape
Teams that ship weekly lean on feature flags to decouple deploy from release, run experiments, and keep a kill switch beside risky changes. The same habit that unlocks speed also creates invisible inventory: flags nobody owns, defaults nobody remembers, and branches of code that still compile years after the marketing launch. Stale flags are not a tidy-code vanity problem. They raise cognitive load, multiply test matrixes, and occasionally resurrect dead paths during an incident.
This playbook targets product-engineering groups of roughly ten to one hundred people—large enough to collide on naming, small enough that a heroic cleanup week still works. You do not need a platform guild of twenty. You need a lifecycle, owners, and a recurring cleanup ritual that treats flags like tickets with due dates.
Separate why a flag exists before you argue about tools. A release toggle that goes to one hundred percent and dies is different from a long-lived permission flag, which is different from an experiment with a traffic split, which is different from an operational kill switch. Mixing those intents in one bag is how “temporary” becomes permanent.
Give every flag a lifecycle and an owner
At creation time, require four fields in your flag admin or ticket template: purpose (release, experiment, ops kill, config), default when removed, owner (a human or rotating role), and a target removal date or review date. Release toggles should default to a removal date within a small number of sprints after full rollout. Experiments should point at an analysis date. Kill switches may live longer, but they still need an owner who can explain the blast radius.
Ownership beats archaeology. When the creator leaves, reassign flags in the offboarding checklist the same way you reassign production services. Orphan flags are how “why is checkout using the legacy tax path” becomes a Friday night mystery.
- Create: purpose, owner, removal/review date, link to ticket or RFC.
- Roll out: progressive delivery with clear success metrics for experiments.
- Stabilize: set to steady state; remove code paths for the losing variant.
- Delete: remove flag checks and configuration; confirm in staging.
Kill switches are not experiments (and naming should show it)
A kill switch exists to degrade or disable a feature fast under load or fraud. It should be obvious, heavily permissioned, and tested in a drill—not buried beside a multivariate copy test. An experiment exists to learn; it should have a hypothesis, a sample plan, and an end. Using one flag for both jobs invites someone to “just flip traffic” during an outage and poison analytics, or to leave an experiment half-on as a silent config forever.
Naming conventions prevent half of the triage pain. Prefer prefixes such as release_, exp_, ops_, and permit_, plus a short feature slug and optional ticket id. Ban cute names that mean nothing six months later. Document whether true means “new path on” so on-call does not invert the switch under stress.
Stale-flag debt shows up as long conditionals, duplicated models, and flaky tests that depend on forgotten defaults. Budget cleanup like security patching: small continuous effort beats a yearly shame spiral.
Run cleanup sprints without stopping the roadmap
Once a month—or every other sprint for high-velocity teams—schedule a flag hygiene block. Export flags older than your policy window. Sort by “past removal date,” “owner departed,” and “100% for N weeks.” Assign a small batch per squad. Success means code deletion and config deletion, not a slide that says “we reviewed them.”
- Archive experiments after calling a winner; delete loser code promptly.
- Collapse release toggles once rollout is done and metrics look stable.
- Re-certify kill switches quarterly: still needed, still wired, still staffed.
- Gate new flags in PR templates so anonymous toggles cannot merge.
Make hygiene visible to product, not only engineering
Product managers who request flags should see the removal date next to the launch checklist. Customer support should know which kill switches exist for partial outages. Finance and data teams should know which experiments still skew funnel metrics. Feature flags are a cross-functional control surface; hiding them in an eng-only admin panel guarantees leftovers.
Measure inventory: count of flags past due, median age of release toggles, and time from 100% rollout to code removal. If those metrics drift up while ship cadence stays high, you are borrowing against future incident time.
Weekly shipping rewards teams that can release dark and light up safely. It punishes teams that never turn the lights off. Install a boring lifecycle, name flags by intent, separate kill switches from experiments, and delete with the same energy you use to launch. That is feature flag hygiene for product teams that intend to still move fast next year.