The Feature Flag Graveyard Nobody's Cleaning Up

Adding a flag takes minutes and feels low risk. Removing one takes longer, since it means confirming nothing still depends on the old code path, updating tests, and actually deleting the dead branch, not just flipping the flag's default. That asymmetry means flags pile up steadily unless removal is treated as a required step of the rollout, not an optional cleanup task someone gets to eventually.

A temporary rollout flag, meant to exist for weeks while a feature ramps up, is a different thing from a permanent configuration switch, meant to exist indefinitely, and both are different from an emergency kill switch, meant to exist forever but never be flipped. Treating all three the same, as if every flag should eventually get deleted, or as if none of them need review, is how permanent switches get mistakenly cleaned up and temporary ones linger for a year.

A flag defaulted to off still costs something: the check runs on every request, the dead code path still needs to compile and pass type checking, and every engineer reading that function still has to hold both branches in their head even though one of them never executes anymore. A flag that's been off for six months with no plan to turn it back on isn't providing optionality, it's just debt wearing a flag's clothing.

Teams in the fastest, on-demand deploy cluster tend to treat flag removal as a normal, low-stakes part of shipping, since a bad removal is trivial to fix with another quick deploy¹. Teams stuck deploying once a month or less treat every change, including flag cleanup, as higher stakes, which makes removal feel riskier than it is and pushes it further down the priority list. If your team deploys frequently, use that: make flag removal a routine, boring part of the workflow, not a special project. And if your team doesn't deploy frequently yet, batch flag removals into a low-risk, well-tested release rather than mixing them into a change that's already carrying real feature risk.

The engineer who added a flag during a feature launch has usually moved on to the next project by the time it's safe to remove. Without an explicit owner for the removal step, a flag can sit fully rolled out and forgotten indefinitely, since nobody feels responsible for closing the loop. Assign the removal, with a rough target date, at the same time the flag is created, not as an afterthought once someone notices it's stale.

Pull every flag currently at one hundred percent on or zero percent off for more than sixty days: those are your strongest deletion candidates, since a flag stuck at either extreme that long usually isn't providing real optionality anymore. For each one, confirm nothing depends on flipping it back, then delete the flag and the dead branch together, not just the flag definition. A tool like ClickUp can hold the list and the assigned owner so the audit produces action instead of another list nobody works from.

Work through each stale flag in this order:

1. Find flags that have sat fully on or fully off for more than sixty days, since they no longer provide real optionality.
2. Confirm nothing still depends on being able to flip the flag back to its old state.
3. Delete the flag and its dead code branch together, not just the flag definition, and update the related tests.
4. Assign an explicit owner for each removal so it doesn't wait on an engineer who has moved on.

Say a service has accumulated eighteen flags over two years, eleven of them stuck fully on or fully off for more than six months. A new engineer reading that service's core function has to mentally resolve every one of those branches to understand what the code actually does today, even though eleven of the eighteen outcomes are already settled. Deleting just those eleven doesn't remove any functionality: it removes eleven unnecessary decisions from every future reader's job, which is most of what flag cleanup is actually buying you.