Feature Flags and Progressive Delivery
Key takeaway
Feature flags let you deploy continuously and release deliberately — shipping unfinished work safely, rolling out to 1% first, and turning a bad feature off in seconds instead of rolling back a deployment. The discipline that makes them work is removing each flag once the decision is made.
Deploying code and releasing a feature are different events, and treating them as one is why release nights exist. Feature flags separate them, which changes how a team can work far more than the small amount of code involved suggests.
What they enable
- Trunk-based development — incomplete work merges behind a disabled flag instead of living on a long branch.
- Progressive rollout — 1% of users, then 10%, then everyone, watching error rates and business metrics at each step.
- Instant kill switch — disabling a broken feature takes seconds and doesn't require a deployment.
- Targeted release — beta cohorts, specific customers, or internal staff first.
- Experimentation — A/B tests as a variant of the same mechanism.
Four kinds of flag, with different lifetimes
- Release flags — hide unfinished work. Live for days or weeks, then get removed.
- Experiment flags — power a test. Removed when the experiment concludes.
- Operational flags — kill switches and load-shedding controls. Long-lived by design.
- Permission flags — entitlements per plan or customer. These are product configuration, not flags, and belong in your authorisation model.
Flag debt is real
A codebase with two hundred stale flags has 2^200 nominal states, untested branches, and conditionals nobody dares delete. Give every release flag an owner and an expiry date at creation, alert when one passes it, and make removal part of finishing the feature rather than a separate cleanup task that never gets prioritised.
Operational advice
- Evaluate flags server-side for anything that affects data or security; a client-side flag is a preference, not a control.
- Default to off, and make sure the system behaves correctly if the flag service is unreachable.
- Log which variant served each request — otherwise debugging a user's report becomes guesswork.
- Don't let a database migration hide behind a flag; schema changes need their own expand-and-contract discipline.