Rule 36 of 38 · Chapter VI — Shipping Is Part of Engineering
Feature-flag the scary things
Why this rule exists
Some changes carry risk you can't fully test away: a new payment path, a rewritten query, a migration touching live data. A feature flag decouples deploying the code from enabling the behavior, so you can ship dark, turn it on for a sliver of traffic, and turn it off in seconds if it misbehaves. That kill switch converts a frightening all-or-nothing release into something you can control.
In practice
Put risky changes behind a flag and roll them out gradually: internal users, then a small percentage, then everyone, watching your metrics at each step. Make sure the off switch is instant and doesn't require a deploy. Test both sides of the flag, and once a change has proven itself, remove the flag promptly so it doesn't become permanent clutter.
When it doesn't apply
Flags aren't free; each one is a branch in your logic and a bit of debt. Don't wrap trivial or easily reversible changes in them. And a flag can't protect you from an irreversible act like a destructive migration, which needs its own careful plan.