Feature flags are easy to add. Here's how to stop them piling up.

Adding a feature flag takes five minutes. Removing it takes forever, because by then the engineer who added it is on another project.

That's flag debt: conditionals for features that shipped months ago and are still sitting in your code.

Three habits that prevent it

1. Pick a category before you write the flag. Martin Fowler's four types (release, experiment, ops, permissioning) each come with an expected lifespan. A release toggle still around after six weeks is a smell.

2. Put an expiry date and a named removal owner in the PR that adds the flag. A name survives a handoff. A team label doesn't.

3. Split authority by action, not by employer.

• Create: whoever owns the service
• Flip in prod: any senior engineer, as long as the flip lands in an audit log tied to a real name
• Remove: needs a second approval, because removal is what breaks forgotten code paths

That third one matters most on blended in-house and contractor teams. If your audit log only knows SSO identities, an external engineer's flips show up as a shared service account, and you won't be able to trace them during an incident review.

The full guide also covers audit logging, using ops toggles as incident kill switches, and why your flag registry belongs in your tech-debt register. Link is in the first comment. 👇