Flags feel free.
Ship dark. Toggle on for staff. Expand to 10%. Forget the flag. Two years later the codebase is a forest of if (flags.neonCheckoutV3_final_FINAL) and nobody knows which branch is real.
Flags are powerful when they are temporary control surfaces. They are toxic when they become forever forks. Ecosystems like OpenFeature help standardize evaluation across services — process still decides whether the flag dies.
Every switch should be allowed to turn off — and to be removed.
What flags are for
- Kill switch for a risky path
- Gradual exposure (cohort, percentage, geography)
- Ops emergency without a full redeploy
- Short experiments with a written hypothesis
What they are not for:
- Permanent multi-tenant branding (use configuration)
- Replacing proper versioned APIs
- Hiding unfinished work for six quarters
The flag ticket fields
When a flag is created, require:
| Field | Example |
|---|---|
| Purpose | Kill switch for new checkout |
| Default | off |
| Owner | payments eng |
| Cleanup issue | ticket link |
| Expiry | date or “after 100% for 14 days” |
| Evaluation points | list of services/components |
No cleanup issue → no flag.
Runtime hygiene
- Centralize evaluation (avoid scattered stringly checks)
- Log decisions on critical paths for support
- Keep defaults safe if the flag service is down (fail closed for risky features)
- Do not nest flags three deep
- Prefer boolean intent over multi-variant spaghetti unless experiment design needs it
Cleanup is the feature
Schedule flag deletion the way you schedule deploys. After full rollout and soak time, remove code paths and the flag definition in one PR. Celebrate deletions in review culture.
A mature team’s flag list is short. A scared team’s flag list is a museum of decisions nobody will reopen.
Closing
Add flags with owners and expiry. Delete them like expired certificates. Otherwise you did not ship flexibility — you shipped a second, worse product inside if statements.
Need rollout discipline on a messy flag estate? Start a project inquiry with your flag list export. Age alone will tell the story.
Flag types
- Release flags — hide unfinished work; delete after ship
- Ops flags — kill switches; may live longer but still reviewed
- Experiment flags — time-boxed; hypothesis required
- Permission flags — prefer real authz systems instead
Mislabeling a permanent permission as a “flag” is how forever-debt starts.
Defaults when the flag service dies
Document fail-open vs fail-closed per flag. Payments and destructive admin paths fail closed. Cosmetic experiments may fail open. Silence on this choice is how outages become security incidents.
Review ritual
Monthly: list flags older than 60 days. Each gets delete, extend-with-new-date, or convert-to-config. No silent survivors.