My Kill Switch Needed a 15-Minute Deploy. That Is Not a Kill Switch

I keep feature flags as constants in a config file in the repository. For most of what I use them for that is the right amount of machinery. Then I needed one to act as a kill switch, and the gap showed up immediately.

A feature I had shipped was hitting the database too hard and had to come off. The flag that controlled it was a constant in a config file, so turning it off meant editing the file and deploying, and a deploy takes me about 10 to 15 minutes. The site was under load for all of it. I also have a flag in that same file that stopped doing anything about 6 months ago and is still sitting there, because nothing ever forces you to go back and remove one.

What happened, in order

1. The feature went out behind a flag, which was the part that worked. Shipping it dark was never the problem.
2. Load went up and the database started struggling. I knew exactly which feature to blame, because it was the one behind the new flag.
3. I edited the constant in the config file, committed, and started a deploy.
4. I waited roughly 10 to 15 minutes while the deploy ran and the database stayed under load. There was nothing else to do in that window.
5. The feature went off and the load dropped. The fix worked. The time it took to reach the fix is the whole complaint.

Two jobs that look the same and are not

What the flag is for	How fast it must flip	Config file good enough?
Hiding unfinished work in production	Whenever the next deploy happens	Yes, this is what it is for
Showing something to one client	Rarely, and planned in advance	Yes, if the list is short
Turning a feature off when it breaks	Now, with the system already degraded	No, a deploy sits in the way

The case for buying one is narrower than the sales pitch

Flag platforms are usually sold on experiments, targeting and staged rollouts. None of that is why my config file fell short. It fell short on one job: changing a value while production is unhappy, without shipping code to do it. That job has a name in the literature, the ops toggle, and it is the one category where changing the value at runtime is the point rather than a convenience.

If that is the only job you need, you do not necessarily need a platform. A single row in a database that the application reads per request gives you the instant flip, costs nothing extra, and keeps the switch inside the system you already run. That is the step most articles skip, because a config file and a paid platform make a cleaner comparison than a config file and one table.

The dead flag is nobody's fault but mine

I have a flag that has done nothing for about 6 months. Buying a platform would not have removed it. Dead flags accumulate because removing one is work with no visible reward, and that is true wherever the flag lives.

Pete Hodgson's write-up of feature toggles, read on 2 October 2026, treats toggles as inventory with a carrying cost and suggests adding the removal task when you add the toggle, giving it an expiry date, or writing a test that fails once the date passes. Mine had none of those, which is why it is still there.

A flag with no end date is permanent, and permanent flags are just configuration with extra steps.

What I would tell someone starting out

Put the flag in a config file and carry on. Reach for something that flips at runtime when you first want one off while the system is struggling, because that is the moment a 15-minute deploy stops being acceptable. Before adding a platform to the bill, check whether a database row covers it, the same way I would check whether the free thing already in front of me is enough, as I did when a spreadsheet stopped being the right place for real data.