Before Your Feature Flags Turn Into a Junkyard — Governing Naming, Staged Rollout, and Kill Switches Across Six Apps

Running staged rollout in 5% increments

Opening a new-feature flag straight to 100% means any problem hits every user. I hash the device's install ID into a bucket from 0 to 99 and control "what percentage is ON" with a numeric remote-config value.

import remoteConfig from '@react-native-firebase/remote-config';
 
// Assign each device to a stable bucket 0..99
function bucketOf(installId: string): number {
  let h = 0;
  for (let i = 0; i < installId.length; i++) {
    h = (h * 31 + installId.charCodeAt(i)) >>> 0;
  }
  return h % 100;
}
 
export function rolloutEnabled(key: string, installId: string): boolean {
  const pct = remoteConfig().getValue(`${key}.rollout_pct`).asNumber(); // 0..100
  return bucketOf(installId) < pct;
}

The operation is simple. Set rollout_pct to 5 to reach 5% of users, then watch the Crashlytics crash rate and key metrics for a day. If nothing breaks, raise it to 25, 50, 100. Because the bucket is stable per device, a user who turned ON does not flicker back to OFF the next day. For an experiment flag, the same mechanism doubles as a 50/50 A/B split.

One caution: do not use an advertising identifier or any value that can track a user for installId. I use an anonymous install identifier generated inside the app so it never becomes a privacy-tracking signal.

Kill switches — the comfort of stopping in 30 seconds

An ops flag exists to stop a feature instantly when something goes wrong. The first one I built was a switch that disables ad display entirely. Wanting to kill ads urgently after an AdMob policy warning is a situation that actually happens.

To make a kill switch effective, you have to design the cache interval. The normal cache is one hour, but an ops flag needs to take effect in an emergency, so I shorten the minimum interval and refetch on launch and on returning to the foreground.

export async function refreshOpsFlags(): Promise<void> {
  // Emergency switches prioritize immediacy: nearly disable cache and refetch
  await remoteConfig().setConfigSettings({ minimumFetchIntervalMillis: 0 });
  await remoteConfig().fetchAndActivate();
  await remoteConfig().setConfigSettings({ minimumFetchIntervalMillis: 60 * 60 * 1000 });
}

In practice, changing the value on the server takes effect on the app's next return to the foreground, and an active restart stops it within 30 seconds. That sense of "I can definitely stop it if I have to" became psychological support for shipping bolder features to production.

Retire dead flags every month

The hardest part of governance is not adding flags but removing them. At the start of each month I spend five minutes on a flag inventory. Anything experiment whose test has ended, and anything release that reached 100% and became permanent, gets its branch deleted from code and removed from remote config.

This is where the kind classification pays off. Keep ops, delete release after it reaches 100%, delete experiment when its test ends — the call is visible from the name alone. Since I started this cleanup, the total flag count across six apps stabilized from near forty to a steady fifteen or so. Fewer flags also lowers the cognitive load on anyone new looking at the config screen.

Build the pattern on one app first

If you are just introducing this, you do not need to align the system across six apps at once. Run one full loop — naming, safe defaults, staged rollout, cleanup — on a single app, and expand only after the operational pattern feels natural in your hands.

I operated the first app for two months before widening to the rest. Just placing the obvious truth — flags are harder to remove than to add — at the foundation of the design prevents much of the six-month wasteland. I hope this helps anyone else wrestling with settings across multiple apps.