← Community

Roll out behind a flag

Ship a behaviour to a slice of users with a kill switch, then delete the flag when it is done — instead of deploying to everyone and hoping. Use when a change is risky, when you need a cohort, or before a large rewrite goes live.

---
name: roll-out-behind-a-flag
category: coding
description: >-
  Ship a behaviour to a slice of users with a kill switch, then delete the
  flag when it is done — instead of deploying to everyone and hoping. Use when
  a change is risky, when you need a cohort, or before a large rewrite goes
  live.
---

# Roll Out Behind a Flag

A feature flag is a way to **change who sees a behaviour without a deploy**.
Used well, it is a kill switch and a cohort. Used poorly, it is a second
configuration language that never dies, with combinations nobody tested.

The method is: default off, a named audience, a way to stop, then delete
the flag in the same generation of work that added it.

## What the flag is for

Write the flag's job in one sentence before you add it.

| Job | Means |
|---|---|
| Kill switch | Everyone can go back to the old path in one change, no deploy |
| Cohort | Named accounts or a percentage, on purpose, measured |
| Experiment | You will look at a metric by a date and then remove a path |

If you cannot tick one of those, you do not need a flag. You need a
standard deploy, or a migration sequence.

A flag is not:

- Permanent configuration ("the Europe stack uses the new tax engine").
  That is config, owned, documented, not a boolean in the code forever.
- A way to merge unfinished work to main. Incomplete work behind a flag
  is still incomplete: it still compiles, still gets reviewed, still
  rusts. Prefer a branch or a narrower slice.

Shared publicly by the author and open for any use. See the Terms.