Feature flag hygiene for small teams
If you own release safety, feature flags are both leverage and debt. Small teams feel that trade‑off quickly.
Use this lightweight routine to keep flags useful without a platform team.
The flag lifecycle (keep it short)
Create -> Ramp -> Stable -> Remove
If a flag has no removal step, it’s already turning into debt.
1) Every flag needs an owner and an expiration
When you create a flag, add:
- owner
- removal date
- rollout plan link
Flags without expiration become permanent and risky.
2) Keep the surface area small
A flag should guard one narrow change. If it controls five unrelated behaviors, no one will turn it off.
Split flags when needed.
3) Make the safe default obvious
You should be able to answer:
- What is the safe default state?
- What happens if the flag is removed?
If you can’t answer, it’s too risky to keep.
4) Review flags every deploy or every week
Pick a rhythm and stick to it. Ask:
- Which flags can be removed?
- Which flags are fully rolled out?
- Which flags are blocking a cleanup?
This takes 10 minutes and prevents long‑term debt.
5) Log changes, not traffic
You only need to know when a flag changes, not every time it’s evaluated. Log the change event and who changed it. Avoid logging user payloads.
A small checklist for each flag
- owner assigned
- expiration date set
- rollout plan linked
- safe default documented
- removal task created
If a flag misses any item, fix it before shipping.
How we run this at DawnOps
We treat flags like short-lived work:
- owner + removal date live with the rollout plan
- cleanup is a real task, not a note
- every deploy review asks: remove, keep, or re-scope
Clean flags make deploys boring. Boring deploys make teams fast.