Feature flags are ops infrastructure, not a product team tool

The pattern

Feature flag as ops tool:

New backend change ships ──▶ [flag: new_auth_flow = true]
                                        │
                              Incident detected (T+12min)
                                        │
                              [flag: new_auth_flow = false]
                                        │
                              Recovery complete (T+13min)
                              
vs. traditional rollback:    Recovery complete (T+75min)

The insight

Most platform teams treat feature flags as a product/A-B testing concern and miss the most operationally valuable use case: instant rollback for any backend change, without a redeployment. The teams with the lowest incident MTTR almost all have the same secret — they can disable any code path in 30 seconds.

The non-obvious part

A feature flag that can disable a code path in 30 seconds is worth more than any runbook during an active incident. It converts a deployment rollback — with its pipeline, merge, and propagation delays — into a config change. Most platform teams own the infra for this and never tell product teams it exists.

My rule

→ Every significant backend change ships behind a flag for at least 2 weeks post-deploy. Flags are cheap. Incidents are not. Make flags a deployment requirement, not an option.

Worth reading

• ▸ Martin Fowler — Feature Toggles pattern (martinfowler.com/articles/feature-toggles.html)
• ▸ LaunchDarkly / Unleash — flag lifecycle management and audit logging best practices