The Toggle Museum: What 200 Dormant Flags Say About Your Roadmap

There is a particular smell in a codebase with too many feature flags. It is not exactly bad code. It is more like a hotel hallway with room-service trays outside every door. Each toggle made sense when someone added it. Now nobody can tell which rooms are occupied.

A team I talked to recently had 212 flags in one service. Forty-one had not changed state in more than a year. Nine were created for a launch that never happened. Six controlled access to a customer commitment that had been renegotiated twice. The flags were not just clutter. They were a paper trail of product decisions, and the trail had gone cold.

That is the useful way to think about a stale-flag audit. It is not housekeeping. It is roadmap archaeology.

Every flag is a decision with a timestamp

Feature flags begin as guardrails: ship behind a gate, test with a cohort, protect a migration, leave a kill switch. All reasonable. The problem starts when the gate stays up so long that it becomes part of the building. A flag that has been on for eighteen months is not a safety net anymore. It is an undeclared product decision.

Most stale flags fall into a few buckets. Launch leftovers never got removed. Experiment residue outlived the experiment. Permission masks became de facto entitlements. Migration scaffolding stayed after the migration. Kill switches became permanent plumbing. Each bucket tells you something different about how the team ships.

The audit is the roadmap review you skipped

Pull the flag list. For each one, capture the owner, the date it was created, the last time it was evaluated, the linked ticket, and the removal condition. If those fields are empty, that is data too. It means the flag was born without an exit plan.

Then look for clusters. If thirty stale flags sit in billing, billing is not a flag problem. Billing is a decision-free zone. If old onboarding flags are still live, you probably have two onboarding flows, two sets of analytics, and no owner for either. If a flag is tied to a sales promise, you have found a commitment that never made it into the product plan.

This is why the audit belongs near the roadmap, not only in the backlog. A flag inventory is a map of unfinished bets. It shows where the team was afraid to commit, where it changed its mind, and where it forgot to finish the job.

Clean up without turning cleanup into a release

The fastest way to kill a flag cleanup is to turn it into a migration project. Do not do that. Keep the ritual small, boring, and repeatable.

Once a month, pick the twenty oldest flags. For each one, make one of three calls: remove it, keep it with an owner and a review date, or renew it with a reason. Removing a flag does not have to mean deleting the code path today. It can mean scheduling the removal, adding a test, and telling the people who depend on it. The point is to force the decision into the open.

A few habits help. Give every new flag an expiration date by default. Put the owner in the flag name or metadata. Link the flag to a ticket before it ships. Track the count of flags older than ninety days. Treat that number like you treat build time: not a moral failing, just a signal.

Not every long-lived flag is debt

There is a difference between a product flag and an operational flag. A kill switch for a critical integration may need to live forever. An entitlement flag for enterprise customers may be legitimate. The test is not age. The test is whether someone can explain why it exists, who owns it, and what would happen if it flipped.

If nobody can answer those questions, the flag is not a safety feature. It is a mystery switch. Mystery switches are how you get a Tuesday afternoon incident that starts with someone asking, Wait, what does this one do?

The payoff is a shorter road to shipping

Teams often worry that flag cleanup will slow them down. The opposite tends to happen. Fewer live flags mean fewer branches in the test matrix, fewer combinations in QA, and fewer conversations that begin with which environment was that in? It also makes the roadmap more honest. You cannot pretend a feature is unlaunched if its flag has been on for a year.

For early adopters, speed is the whole game. A museum of toggles is a museum of deferred decisions. The tour is worth taking before the next launch adds another wing.