A Checklist for Cleaning Up Feature Flags Before They Become Their Own Codebase

A flag that's been fully rolled out, or fully rolled back, for a defined stretch of time, say a full quarter, with no changes, is a strong candidate for removal: the decision it was meant to test has effectively already been made. Pull this list directly from your flag management tool's history rather than relying on memory of which flags are "probably done."

The pitfall here is treating a long stretch of stability as proof the flag is safe to remove immediately. It's a strong signal, not a guarantee; check the next few items before deleting anything.

Search the codebase for the flag's key, not just in the feature it was originally built for. Flags have a way of getting reused or checked in unrelated code paths added later by someone who didn't know the flag's original intent, and removing it without finding every reference can silently change behavior somewhere nobody's watching.

This is also where old, unrelated experiments sometimes surface: a flag added for a specific A/B test that got wired into an analytics event or a logging condition long after the original test ended, in a way that isn't obvious from the flag's name alone.

Once you're confident a flag is safe to remove, delete both the flag definition and the code path it disabled, not just one or the other. Removing the flag but leaving dead code behind, or leaving the flag defined but unused, both create a smaller version of the same confusion the cleanup was meant to fix.

Keep this as its own pull request, separate from any feature work happening at the same time. A flag removal mixed into an unrelated change is much harder to review carefully, and careful review is exactly what this step needs.

The safe removal order, start to finish:

1. Confirm the flag has been fully on or fully off, with no changes, for a defined stretch such as a quarter.
2. Search the codebase for the flag key everywhere, not only in the feature it was built for.
3. Separate genuine leftovers from deliberate kill switches, and tag the kill switches so they are not removed by mistake.
4. Remove the flag definition and its dead code path together in one focused pull request, kept separate from feature work.

Some flags that look fully and permanently rolled out are deliberately kept as an operational kill switch, a way to quickly disable a feature if something goes wrong, even though the feature itself is fully launched. Removing one of these isn't a cleanup, it's removing a safety mechanism, often without anyone realizing until the next time it's needed and isn't there.

Tag these explicitly in your flag management tool so they're excluded from routine cleanup sweeps, and review them on a separate, longer cadence instead of deleting them alongside genuinely stale flags.

A single big cleanup effort feels satisfying but the flag count creeps back up the same way it did the first time unless the review becomes routine. Add a short flag review to a regular cadence, monthly or quarterly depending on how quickly your team ships flagged changes, and treat a growing count of stale flags as a signal the review cadence itself needs to tighten, not just a backlog to eventually get to.

A flag named after the specific decision it supports, with an expected removal date set at creation time, is far easier to evaluate six months later than a flag named after a generic feature with no context attached. Make an expiry date a required field when a flag is created, even if it's just a rough estimate, since a flag with no expectation of when it should be revisited tends to be the one still sitting there years later.

This small habit at creation time does more to keep the flag count manageable long-term than any single cleanup sweep, because it turns "forgot this existed" into "this is overdue," which is a much easier thing to act on.