The Feature Flag Cleanup Discipline

Feature flags accumulate. The discipline that prevents flag-debt: every flag has an owner and a death date.

When you create a flag

Flag debt starts at creation, not at retirement. Set the policy at the moment the flag enters the system or it never gets cleaned up.

• Owner. A named engineer accountable for retirement; flags without owners orphan within a quarter.
• TTL. Default 90 days; extensions require written justification, not a Slack nod.
• Purpose doc. One paragraph in the flag platform: what gates this flag, what happens when it is removed.
• Removal cost. Note up front whether retirement is a code-only change or also touches data, schemas, or third-party config.

During the flag's life

Most flags become stale long before anyone admits it. Continuous tracking turns ambient flag debt into a visible queue.

• Ramp tracking. Flags fully ramped (100% on, 0% off) for 30 days are retirement candidates by definition.
• Traffic tracking. Flags with no evaluations for 30 days are usually safe to remove without owner negotiation.
• Quarterly audit. Surface stale flags to their owners; owner either justifies or schedules removal.
• Aging chart. Histogram of flags by age; long tail past the TTL is the visible debt to attack.

Retiring a flag

Retirement is two changes that have to happen together. Skip either and the flag returns as zombie code or platform clutter.

• Code change. Remove the flag check; hard-code the chosen path; delete the now-dead branch.
• Platform change. Delete the flag from LaunchDarkly, Statsig, or whatever holds the rule.
• Regression suite. Tests must pass with the flag gone; if they do not, retirement was premature.
• Notify consumers. Downstream services or experiments referencing the flag get a heads-up before the platform delete.