Shipping risky work behind flags without losing the plot
By Adrian Vasquez · · 9 min read
Feature flags let you learn in production. They also quietly become the most tangled code in your app unless you give them a lifecycle.
Flags are a delivery tool, not a config system
Rebuilding a regulated onboarding flow meant replacing identity verification while thousands of people were mid-application. A flag let us route 5% of new applicants through the new stages, compare completion honestly, and roll back in seconds rather than in a hotfix.
The failure mode is scope creep: flags start as temporary release valves and end up as permanent branching business logic that nobody dares delete.
Every flag gets an owner and an expiry date
Each flag is registered with a name, an owner, a hypothesis and a removal date. A weekly job opens a ticket for any flag past its date. Release flags live weeks; a handful of permission flags are marked long-lived and reviewed quarterly.
Flags are read at one boundary — a route or a container — and never sprinkled through leaf components. That keeps removal a small diff instead of an archaeology project.
Decide with evidence, then clean up
Before the rollout we wrote the number that would end the experiment: activation above 75% at the 10% cohort. It reached 84%, so the ramp was mechanical rather than political, and the old path was deleted the same sprint.
The discipline is unglamorous and it is the whole trick: cleanup is part of shipping, not a follow-up you hope to fund later.
