There is a moment every developer knows. The deploy finishes, the new feature goes live for everybody at the same time, and you sit there watching the error dashboard like it is a horror movie. If something breaks, it breaks for all users at once. Rollback takes time. Support tickets pile up. Somebody important asks “what happened?”, usually in all caps .
Feature flags changed that moment for me. Today, deploys are boring on my team. And boring deploys are one of the best gifts you can give to a business.
What a feature flag is
The idea is simple. You wrap a new feature in a condition. If the flag is on, the user sees the new thing. If the flag is off, the user sees the old thing. The flag lives in configuration, not in code, so you can flip it without a deploy.
That small idea separates two things that were always glued together. Deploying code and releasing a feature. With flags, you can deploy on Tuesday and release on Friday. You can release to 1% of users first, then 10%, then everybody. You can turn it off in seconds if something goes wrong.
Pete Hodgson wrote the best article I know about this, published on Martin Fowler’s site. If you read only one thing about feature flags, read that one. It explains the different types of flags, release flags, experiment flags, ops flags, permission flags, and how each type should live a different length of time.
Why the business should care
Let me translate flags into business language, because this is where they really shine.
First, risk. A release to 100% of users is a big bet. A release to 2% of users is a small bet. If the new checkout flow has a bug, you find it when twenty people hit it, not twenty thousand. The cost of a mistake drops by a huge factor. When I ran an agency back in Brazil, a bad release meant a client calling my phone at night. I would have paid good money for this kind of safety back then.
Second, speed. Without flags, teams hold features in long lived branches, waiting for the “perfect” release moment. Those branches rot. Merges become painful. With flags, you merge small pieces into main every day, hidden behind a flag that is off. The code ships dark. Integration pain almost disappears, and the team moves faster.
Third, learning. This is the underrated one. A flag lets you run an A/B test on a real business hypothesis. Does the shorter signup form increase conversions? Show version A to half the users and version B to the other half, and measure. You stop arguing about opinions in meeting rooms and start collecting answers from real customers. The product manager stops guessing and starts knowing. That is worth more than any clever code.
Fourth, sales and timing. Marketing wants the feature to go live at 9am on launch day, together with the announcement. Without flags, that means a risky deploy at 8:55am with everybody nervous. With flags, the code has been in production for two weeks, tested quietly, and at 9am somebody clicks a toggle. Done.
The dark side, flag debt
Now the honest part. Feature flags rot.
Every flag is an if statement in your code. Every if statement is two paths to test, two paths to understand, two paths that can break. One flag is fine. Fifty old flags that nobody remembers is a nightmare. I have seen codebases where nobody could say with confidence which flags were on in production, or what would happen if you flipped one. That is not flexibility. That is a minefield.
The problem is that removing a flag is nobody’s favorite job. The feature shipped, the team moved on, and the dead flag stays in the code forever. Hodgson calls this out clearly in his article. A release flag should live days or weeks, not years.
Here is what works for us.
- When you create a flag, create the cleanup ticket at the same time. The flag is not done until it is deleted.
- Put an owner and an expected removal date on every flag.
- Review the flag list every month or two. Old flags that are 100% on get their dead code path removed.
- Keep experiment flags separate from release flags, because they have different lifetimes.
Treat flags like milk, not like wine. They do not get better with age.
How I started
You do not need a fancy commercial tool on day one. The first time I tried this, it was just a config file with flag names and on/off values, enough to learn the habit. The tools become worth it later, when you want percentage rollouts, user targeting, and audit logs.
I started with one scary feature. Wrapped it in a flag. Shipped it dark. Turned it on for my own team first, then a small slice of users, then everybody. That release was so calm compared to the old way that I never went back.
The first time you turn off a broken feature in ten seconds, instead of a forty minute rollback while customers suffer, you will understand the value in money terms. Less downtime, less support cost, less stress on the team. People sleep better. Teams that sleep better build better software.
Ship fast, but make it boring. Feature flags are how.
Pax et bonum.