A flag you can flip beats a rollback you have to deploy
A full deployment rollback takes however long your deployment pipeline takes, even in the best case. A well-designed feature flag can disable a misbehaving code path in seconds, with no deployment at all — a materially faster lever during an active incident, when every minute of impact matters.
This only works if the flag was designed to gate the actual failure-prone logic, not just the UI surface of a feature — a common gap that only becomes visible during the incident it was supposed to help with.
Designing flags for this use case specifically
Wrap genuinely risky operations (new payment logic, a new recommendation algorithm, an external integration with uncertain reliability) in a flag from day one, specifically so there's an instant off-switch available if it misbehaves in production, independent of the original release-management reason for adding a flag at all.
Keep a short, known list of 'kill switches available' visible to the on-call team, so this capability is actually used during an incident rather than discovered afterward in a post-mortem.
The discipline this requires
Flag sprawl without cleanup becomes its own source of complexity and incidents — stale flags nobody remembers the purpose of are a liability, not a resilience asset. Treat flag removal as part of the definition of done for the feature it was built for, not a someday task.
Done with this discipline, feature flags earn their keep twice: once at release time, and again the day something goes wrong in production.
The fastest rollback is the one that doesn't require a deployment at all.MNB Software Practice
Key actions
- Wrap genuinely risky operations in a flag from day one
- Maintain a visible list of available kill-switches for on-call
- Gate the actual failure-prone logic, not just the UI surface
- Remove flags as part of the feature's definition of done