rollfuse
← Back to blog

Five Rollout Patterns That Stop Scaling Past 50 Active Flags

A handful of flags is easy to reason about by hand: everyone on the team roughly knows what each one does, who owns it, and whether it's safe to remove. That stops being true well before a hundred flags, usually somewhere around 50, which is where most of the patterns below start to visibly break.

1. One threshold, copied by hand into every rollout

If your latency or error-rate guardrail threshold lives as a literal number typed into each new rollout, recalibrating it means finding every place it was copied. This is exactly what Guardrail Templates exist to fix: define the policy shape once per project, install it onto any rollout, and a recalibration is a single edit instead of an audit.

2. No owner recorded anywhere but tribal memory

A flag with no recorded owner is fine until the person who created it changes teams. At small scale, "ask around" works. Past 50 flags, it doesn't. Someone eventually has to decide whether a flag with no clear owner is safe to delete, and "nobody remembers" is not an answer that survives an incident review.

3. Targeting rules re-derived per flag instead of shared

If the same segment ("internal users," "EU-region traffic," "customers on the Enterprise tier") gets re-expressed as a fresh targeting rule on every flag that needs it, a change to what that segment means (a new internal domain, a plan rename) requires updating every flag individually. A reusable segment, defined once and referenced by every rule that needs it, turns that into a single edit.

4. No distinction between a permanent flag and a temporary one

A rollout flag (ship this feature gradually, then remove the flag) and a permanent operational flag (kill switch, entitlement gate) have different lifecycles, but at small scale they tend to live in the same undifferentiated list. Past 50 flags, that list becomes unscannable. You can't tell at a glance which flags are stale rollout scaffolding that should have been deleted months ago.

5. Flag removal has no forcing function

Nothing about a feature flag naturally prompts its own deletion once the rollout finishes. Without an explicit habit (a review at 100% completion, a dashboard of flags that have sat at 100% for N weeks), flags accumulate indefinitely, and the "five patterns that don't scale" above compound faster the longer that list grows.

None of these are exotic problems. They're the ordinary shape of what happens when a practice that worked for ten flags gets extended, unmodified, to two hundred.