A codebase has 340 feature flags, most of them permanently on. What is the problem and how do you fix it?

The problem is combinatorial and it is not theoretical

Every flag doubles the number of possible code paths. At 340, the number of configurations is unbounded and only one of them is tested — the one production happens to be in.

Concretely: a flag left on for two years has a dead off-branch nobody has run, which will not work if anyone ever flips it. So the flag is not actually a safety mechanism, which is what it was added for.

Secondary costs: the conditional logic makes the code harder to read, static analysis is defeated, and the flag service becomes a runtime dependency for every code path.

Classify before deleting

Release flags — temporary, for progressive rollout. These should have been removed after the rollout completed, and most of the 340 are these.

Operational flags — kill switches and circuit breakers, deliberately permanent. Keep, and exercise them so the off-branch is known to work.

Permission and entitlement flags — actually configuration, not flags. They belong in a configuration or entitlement system, not the flag service.

Experiment flags — temporary, and the experiment ended.

Remove with a process, not a project

Give every new release flag an expiry date at creation, and fail the build when it passes. That stops the growth, which is the more important half.

Then remove the existing ones by age, oldest first, in small batches. Each removal is a code change with a test, and batching them makes the review meaningless.

The rule that keeps it clean

A release flag's lifecycle ends at the rollout, not at the release. Making removal part of the definition of done for the change that introduced it is what prevents the next 340.