How short-lived toggles quietly turn into a shadow configuration system, and a lifecycle model that survives a large org.
Ten boolean feature flags create over a thousand possible versions of your application. Twenty create more than a million. In my experience, your test suite covers maybe a dozen of those combinations, and your users find the rest in production.
The flag nobody will delete
Every team I have worked with has at least one flag like this. Somebody added it for a launch two years ago. The person who wrote it has moved teams or left the company. The flag is still in the code, still being evaluated on every request, and nobody will touch it. Not because it does something important, but because nobody knows what happens if you remove it. So it stays. And then you multiply that one flag by the hundreds of others sitting in the same codebase, each with its own small cloud of uncertainty.
This is the part the industry does not talk about honestly. We were sold the easy half. Adding a flag is one line. Turning it on is a click in a dashboard. That part is genuinely cheap, and the vendors are happy to show you how fast it is. The hard half, turning the flag off and deleting it cleanly, was left for you to figure out later. Pete Hodgson calls this the carrying cost of a toggle, and most teams never pay it down.
That carrying cost is the real subject here. This article is about why flags turn…