Zhivko Todorov
ALL CASE STUDIES

CASE 172 · UNDERTOW · 2024

FEATURE FLAGSGOVERNANCEAPPCONFIGCLEANUP

Feature flags that retire themselves when they should.

A B2C streaming company had 480 active feature flags in their feature-flag service. About 60% had been at 100% rollout for over a year — flags that should have been removed but were technical debt nobody scheduled. We built a governance layer that flagged stale flags and automated the cleanup.

INDUSTRY

B2C streaming

DOMAIN

PLATFORM

DELIVERED

2024

STACK

AWS APPCONFIG·BACKSTAGE·GITHUB ACTIONS·CLOUDWATCH METRICS·OPENREWRITE (CODE)

RESULTS

What changed, by the numbers.

STALE FLAGS RETIRED

247

IN 90 DAYS

ACTIVE FLAG COUNT

480 → 198

CLEAN INVENTORY

NEW-FLAG LIFECYCLE

ENFORCED

OWNER + EXPIRY DATE

CODE COMPLEXITY

−12%

CYCLOMATIC, FLAG-RELATED

HOW IT WENT

Feature flags were supposed to be ephemeral — a flag exists for the duration of a rollout, then it gets removed. The reality was that flags accumulated. Every code path was bifurcated by some long-dead flag. The cognitive cost was real.

We introduced lifecycle metadata: every new flag had an owner and an expiry date. Backstage rendered the stale-flag inventory per team. GitHub Actions surfaced cleanup PRs using OpenRewrite to mechanically remove the flag-gated code paths. CloudWatch metrics confirmed the path that survived was the production-serving one.

247 stale flags retired in 90 days. Active flag count dropped from 480 to 198 — most of the rest are legitimately in-flight or feature-gated for sales reasons. Code complexity dropped 12% on the flag-related portions. New flags have owners and expiry dates by policy.

READY WHEN YOU ARE

Let's get your AWS bill (and architecture) in order.

The discovery call is free. You walk away with at least one concrete idea — even if we never work together.

Or email directly →