Feature Flags, Config, and Experiments Are Not the Same Thing

A release flag exists to decouple deploy from release — it's meant to be short-lived, flipped on for everyone once the rollout is confirmed safe, and deleted from the codebase shortly after. Long-lived configuration (which pricing tier gets which limits, which region uses which provider) isn't really a 'flag' in the same sense at all; it's application configuration that happens to be toggleable, and treating it like a temporary release flag means it accumulates in the same system as things meant to be deleted, making it hard to tell which flags are safe to clean up and which are permanent. Experiment flags (A/B tests) have yet another lifecycle: they need randomized, sticky assignment per user, they need to report into an analytics pipeline, and unlike a release flag they're not 'done' when one variant wins, they're done when the losing variant's code is deleted, which is a step teams frequently skip. Conflating these three in a single flag system is how codebases end up with hundreds of flags nobody's confident are dead, because a release flag left in the config category by mistake looks identical to permanent configuration, and cleanup requires archaeology instead of just checking a lifecycle field. Whatever tooling you use, tag each flag with its type and an owner at creation time, and treat 'flags with no clear removal plan' as tech debt to review on a schedule, the same way you'd review stale feature branches.