The Switch Nobody Owns: Taming Feature Flags After Launch

Feature flags are one of those tools that feel almost too useful. Need to ship a new checkout flow to 10 per cent of users? Flag it. Want to hide an unfinished dashboard from everyone except the design team? Flag it. Need to turn off a wobbly integration before the Friday afternoon support handover? Flag it.

Then launch week ends. The flag stays. Six months later, nobody is quite sure whether that toggle is keeping the lights on or quietly turning them off.

That is not a dramatic failure. It is ordinary drift. And for small UK teams, where the person who added the flag may have moved on, gone on holiday, or simply forgotten the context, it creates a special kind of mess: hidden dependencies, confusing support paths and access routes that were only meant to exist for a fortnight.

Why "just for launch" becomes permanent

Feature flags are designed to be temporary, but nothing about a flag forces it to be temporary. There is no calendar reminder built into the concept. A flag is just a condition in code, a row in a database, or a switch in a dashboard. If it keeps returning the right value, nothing breaks.

The trouble starts when the flag outlives its purpose. A toggle that once guarded a beta feature may now be the only thing stopping a half-finished workflow from appearing to customers. A kill switch added during an incident may become the de facto way to disable an integration. A permissions flag may be silently granting access to a contractor who left last spring.

None of that is obvious from the admin screen. Most flag dashboards show names, states and maybe a timestamp. They rarely explain why the flag exists, who owns it, or what will break if you turn it off.

Start with a blunt inventory

You cannot audit what you cannot see. Before deciding what to keep, gather every flag you can find. That means the flag platform, certainly, but also configuration files, database tables, environment variables and the comments in code where someone wrote "temporary" three years ago.

Split the list into three rough groups:

• Customer-facing flags that change what users see or can do.
• Operational flags that control integrations, background jobs or emergency shut-offs.
• Internal flags that affect staff tools, admin panels or test accounts.

You do not need a perfect taxonomy. You need a list that lets you ask sensible questions. If a flag does not appear in any list, that is the first finding: it is running, but nobody is tracking it.

Ask what breaks if you flip it

For each flag, the key question is not "is it on?" but "what happens if we change it?" That is where stale flags get interesting.

A flag added for a launch may now control a feature that customers depend on. Turning it off could remove a button, break a checkout step or hide a support article. A flag that looks unused may still be read by a cron job or an integration that nobody associates with the main product.

If you can safely test in staging, do that. If you cannot, check logs and code references. Look for the flag name in your repository, your ticketing system, your runbooks and your support macros. If it only appears in the flag dashboard, that is a strong sign it is either dead or dangerously undocumented.

Kill, keep or document

Once you know what a flag does, you have three sensible outcomes.

Kill it. If the feature is fully launched, the old path is gone and nobody needs the off switch, remove the flag and the dead code behind it. This is the best outcome, but it needs care. Remove it in a controlled change, with a rollback plan that does not rely on the flag you just deleted.

Keep it properly. Some flags deserve to stay. A genuine kill switch for a payment provider, a seasonal feature or a regulatory toggle may need to exist permanently. That is fine, as long as it is labelled as permanent and has a documented owner and purpose.

Document it and set an expiry. For flags that are not ready to die but should not live forever, write down the owner, the reason, the expected review date and the conditions for removal. Put that information where the next person will actually look: the flag description, the ticket and the runbook.

Give every survivor an owner and a date

A flag without an owner is a rumour with a switch attached. Every flag you keep should have a named person or team responsible for it. Not a generic inbox. A person who can answer "what does this do?" and "when will we remove it?"

Add an expiry or review date. It does not have to be precise. "Review after the next billing cycle" is better than nothing. For small teams, a quarterly review is usually enough, provided it actually happens. Put it in the same calendar as your access review or your renewal check-in. Boring rituals are more likely to survive than heroic clean-ups.

Make the review short enough to repeat

A flag audit can become a monster if you let it. Do not try to document every flag in one go. Start with the oldest, the ones with no description and the ones that touch customer access or money.

A lightweight quarterly review might take 30 minutes:

1. Export the flag list.
2. Flag anything with no owner, no description or a review date in the past.
3. Pick three to investigate.
4. Remove one, document one and schedule one.
5. Update the runbook and tell support.

That is not glamorous, but it works. The aim is not a perfect flag inventory. The aim is to stop "just for launch" settings from becoming permanent infrastructure by accident.

Check the support path too

Flags are not only an engineering concern. If a customer reports a missing button, can your support team tell whether a flag is responsible? If an integration fails, does the on-call rota know which toggle to check? If a contractor needs access, is there a flag that quietly grants more than intended?

Add a short section to your support runbook: where flags live, who can change them and what to check before escalating. That one page can save a lot of guessing during a busy Monday morning.

Feature flags are supposed to make change safer. They do that best when they are treated as temporary tools with a clear purpose, not as invisible settings that nobody dares touch. A small, regular tidy-up keeps the switches useful and stops the old ones from running the show.