Feature flags are the cheapest insurance you can buy

The idea

Deploying means the code is running on your servers. Releasing means customers can see it. Treat them as two separate steps and a lot of risk goes away.

A feature flag is a switch in your configuration. The code ships behind it, switched off. When you're ready, you turn it on for yourselves, then a few customers, then everyone. If something breaks, you turn it off. No rollback, no redeploy.

Why it matters more now

When part of the code is generated or the feature depends on a model you don't control, behaviour in production is harder to predict from tests alone. A flag gives you a way to find out with ten users before you find out with ten thousand.

The traps

• Flags that never die. Each flag doubles the paths through the code. Give every flag an owner and an expiry date, and delete it once the rollout is done.
• Flags inside flags. Two flags that depend on each other are a bug waiting for a Friday evening.
• Untested off state. Check that your product works with the flag off, since that's the state you'll rely on in an emergency.
• Permission by flag. A flag controls rollout, not who is allowed to do what. Keep authorization separate.

What to do this month

1. Start with one risky feature. Put the next release of it behind a flag.
2. Plan the ramp. Staff first, then 5% of users, then 25%, then everyone. Decide in advance what you'll watch at each step.
3. Pick the kill criteria. Error rate, support tickets, a business number. Agree on what makes you switch it off.
4. Put an expiry on every flag. Review the list monthly.
5. Make the switch fast. If turning something off needs a deploy, it isn't a kill switch.