Feature flags started as liberation. Deploy anytime! Test in production! Gradual rollouts! Dark launches! A/B test everything! We were true believers.
Three years later, we had 847 feature flags. The codebase was incomprehensible.
"What does this code path do?"
"Depends on flag_new_checkout_v3, flag_experiment_pricing_2024, and flag_rollout_europe_billing. If all three are on, it does X. If only the first two, Y. If just the first one with flag_ab_test_q4 also enabled, Z."
The combinatorial explosion was devastating. With 847 flags, we theoretically had 2^847 possible system states. Of course, most combinations never occurred. But enough did that debugging production issues became archaeology.
The Timeline of Decay
Year 1: 50 flags. All well-documented. Clear ownership. Cleanup happens.
Year 2: 200 flags. Documentation slipping. Some flags orphaned when owners left. "Just leave it on, probably fine."
Year 3: 847 flags. Nobody knows what half of them do. Removing any flag risks breaking something. Flags guarding flags. Flags that were supposed to be temporary from Year 1 still in code.
The Incidents
The Midnight Deploy: Engineer deployed at midnight because "flags are off by default." Except a Terraform misconfiguration had turned 43 flags on in production. 3-hour outage.
The Zombie Feature: Support ticket about a feature that "used to work." Investigation revealed the feature was behind a flag that had been killed when its owner left the company. The code still existed; the flag was just off forever. Nobody knew the feature ever existed.
The Performance Mystery: 40% latency regression. Two weeks of investigation. Cause: interaction between three flags that individually had no performance impact but together triggered an O(n²) code path that only activated under specific conditions.
The Great Cleanup
We dedicated a team to flag cleanup. Six engineers for six months.
Step 1: Inventory. Actually list all 847 flags with purpose, owner, and creation date. 340 had no documented purpose. 280 had owners who'd left the company.
Step 2: Classification. Currently active rollout (keep). Completed rollout, can remove (most). Unknown purpose, appears on (risky to touch). Unknown purpose, appears off (probably safe).
Step 3: Careful deletion. One flag at a time. Deploy. Wait. Monitor. Repeat. Each flag removal was its own mini-project because the dependencies were unknown.
After six months: 847 → 52 flags. We kept only the ones with clear, ongoing purpose.
What We Do Now
We didn't ban feature flags. We constrained them severely:
- Maximum lifetime: 30 days for experiments, 14 days for rollouts. After that, the flag must be removed (all code paths converged) or escalated to leadership.
- Mandatory ownership: No flag without an owner. If owner leaves, flag must be resolved before their last day.
- Weekly audit: Automated report of all flags older than their intended lifetime. Public shaming in Slack.
- Complexity tax: Each new flag requires review demonstrating why shipping the feature complete isn't possible.
Current flag count: oscillates between 15-30. Never more than 40.
The Alternative: Ship Complete Features
Most flags existed because we shipped incomplete features. "We'll hide it behind a flag until it's ready." Then it was never ready. Or it was ready but nobody removed the flag.
Now we ship complete features or don't ship. A feature is done when it's live for everyone with no flags. If it's not ready for everyone, it's not ready—keep working on it.
This feels slower. It's actually faster. The time saved on flag management, debugging, and cleanup far exceeds the time spent polishing features before release.
Feature flags promised control. They delivered chaos. Ship features complete. Your future self will thank you.
Written by XQA Team
Our team of experts delivers insights on technology, business, and design. We are dedicated to helping you build better products and scale your business.