Feature flags are one of those engineering practices that look like extra work until you realize how much pain they save.
Here is the change we made about two years ago: every non-trivial change ships behind a flag. Off by default. Promoted gradually — internal team first, then 5% of users, then 25%, then everyone. The whole thing is instrumented in our analytics so we can see if conversion drops or errors spike at each step.
What this gives us:
- Deploy decoupled from release. We push to production whenever it is ready; we turn things on whenever the business needs them on.
- Instant rollback. Any flag can be killed in seconds without a deploy.
- Safer big rewrites. New paths run alongside old paths until we trust them.
The cost is real — flags add complexity, and dead flags pile up if you do not clean them. So we set a rule: any flag that has been at 100% rollout for two sprints gets retired in the next sprint. Calendar event, no exceptions.
It is not glamorous. But it is the difference between a calm Thursday deploy and a frantic Sunday revert.