Opening the book…
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.
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.
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.