Feature Flags

A feature flag decouples deploy from release. The code ships dark, and a runtime switch decides who sees it. That separation is what makes trunk-based development and continuous deployment practical, because unfinished work can merge without being visible.

The kinds are worth naming, because they have different lifespans. Release toggles hide work in progress and should be removed once the feature is fully on — days or weeks. Operational toggles, or kill switches, let you disable an expensive or risky subsystem under load, and live as long as the subsystem does. Experiment toggles drive A/B tests and die when the experiment concludes. Permission toggles gate features by plan or role and are effectively permanent.

Progressive rollout turns a release into a dial: one percent, then ten, then fifty, watching error rates and latency at each step. If something is wrong, the blast radius is bounded and the fix is turning the dial back — no rollback, no redeploy.

Dark launching runs new code in production without exposing its output: you call the new path, discard the result, and compare it to the old one. It gives you real production traffic against untested code with no user-visible risk.

Flag debt is the real cost. Every flag is a branch in your code and a multiplier on the states you must reason about. Ten flags is a thousand possible combinations, almost none of which are tested. Flags that outlive their purpose are how a codebase becomes impossible to reason about, so a release toggle needs a removal date the way a TODO needs an owner.

Flags are not free at runtime either. Evaluation should be fast, local, and fail safe — if the flag service is unreachable, the application must still start and take a sensible default.