Release Toggle

Deploying code and releasing a feature are different events. A release toggle separates them: the code ships disabled, is enabled for internal users, then a small percentage, then everyone — and is then removed.

The critical property is its intended lifetime, which is days to weeks. It exists to make a rollout controllable, and once the feature is fully released it has no remaining purpose.

Why the distinction matters

Four different mechanisms are called "feature flags", with completely different lifetimes: release toggles (weeks), experiment flags (the duration of the experiment), operational toggles and kill switches (permanent by design, part of the degradation ladder), and permission flags — which are not flags at all but product entitlements belonging in the domain model.

Almost all accumulated flag debt is release toggles that were never removed, and it arises from applying one policy — or no policy — to all four categories. The operational toggle should be permanent and maintained; the release toggle should be deleted; treating them the same produces either an unmanaged codebase or a missing resilience mechanism.

Implementation patterns

• Declare the type and an expiry date when the flag is created. A release toggle without an expiry is permanent by default, which is how the debt begins.
• Removal is part of the feature's definition of done, not a follow-up ticket.
• Automated stale-flag reporting — past expiry, fully rolled out for a period, or never evaluated — raising a task against the owning team.
• A hard cap on concurrent release toggles per team, which forces cleanup by making it a constraint rather than an aspiration.
• Keep the flag out of the data model, so removal is a code change rather than a migration.
• Avoid nesting and interaction. Flags whose effect depends on other flags produce a state space nobody can reason about.
• Test the two states that will actually occur — the current production configuration and the target one. Testing all 2^N combinations is impossible; testing the two that matter is straightforward, and is what teams omit.
• Evaluate from a cached local snapshot with a safe default, so the flag service being unavailable degrades to last-known-good — flag evaluation on the request path with no fallback is a genuinely common cause of incidents.

Industry example

Trunk-based development at scale depends on this pattern: continuous integration into a single branch requires that incomplete work can be merged safely, and a release toggle is the mechanism. The practice is near-universal in organisations deploying many times a day, and so is the resulting debt — codebases with hundreds of flags, most long since fully rolled out, are a routine finding.

The organisations that avoid it are consistently those that treat expiry as mandatory metadata and report on it automatically, rather than those with better intentions.

Failure scenarios

• No removal step, leaving the flag permanently.
• Combinatorial explosion, where production runs a flag configuration that has never been exercised and the bug appears only for users in that combination.
• Flags persisted in the data model, making removal a migration.
• Nested flags, producing behaviour nobody can predict.
• Two implementations maintained indefinitely behind a flag that became permanent.
• The flag service as a hard dependency, so its outage is an outage.
• Kill switches conflated with release toggles and cleaned up — removing a resilience mechanism during a tidy-up.
• Operational toggles never exercised, so a switch not thrown in six months does not work when needed.

Trade-offs

Every flag is a branch in the code that must be read, reasoned about and tested, and it is a real comprehension cost for everyone who touches that area. For a few weeks that cost is entirely worth paying for a controllable rollout; over three years it is a substantial and pointless tax.

Flags also weaken the guarantee that what was tested is what runs. The tested configuration and the production configuration may differ, and the more flags exist the more likely that is — which is why testing the specific transition matters more than testing coverage.

The trade is temporary code complexity in exchange for decoupled deployment and controllable, reversible rollout — an excellent trade with a short lifetime and a poor one without. The discipline is entirely in the removal, and the only mechanism that reliably delivers it is making expiry mandatory and reporting on it automatically.

Interview question

"We have four hundred feature flags and nobody knows which are safe to remove. Tell me how you would work out which is which, what you would change so this does not recur, and which of those four hundred you would deliberately keep forever."