The Practical Developer

Feature Flags That Pay Rent: The 4 Flag Types And When To Delete Each

September 16, 2022 by The Practical Developer

Most teams have one feature-flag system and four kinds of flags pretending to live in it. Release toggles, ops toggles, permission toggles, and experiments behave differently, decay differently, and need different cleanup rules. Here is the taxonomy that prevents flag debt from eating your codebase.

productivity

devops

process

A control panel of switches — the visual that everybody draws when describing feature flags, but actually managing them is harder

A typical mid-stage codebase has 200 feature flags. About 30 of them are on for everyone and could have been deleted a year ago. Twenty are off for everyone and exist only because the engineer who shipped the kill switch left the company. Forty are scoped to “internal users” but the internal-users group has not been updated since the company’s first office. The rest are doing real work, but you cannot tell which is which without reading every check site.

This is what flag debt looks like. The cure is not “use feature flags less.” Feature flags are one of the highest-leverage techniques in modern delivery. The cure is treating the four kinds of flags as four different things — because they have different lifetimes, owners, and cleanup rules.

The four kinds

Release toggles. Short-lived. Wraps a half-built feature so the unfinished code can ship to production behind an off switch. The flag exists to decouple deploy from launch. Once the feature launches and survives a week, the flag is deleted. Lifetime: days to weeks. Owner: the engineer shipping the feature.

Operational toggles. Long-lived. A kill switch you flip in an incident — “disable the new pricing API,” “fall back to the v1 search backend.” Designed to live in the codebase indefinitely as a safety mechanism. Lifetime: as long as the feature exists. Owner: the on-call rotation.

Permission toggles. Long-lived. Controls who sees a feature: free vs paid, beta-tester opt-in, region-specific. Functionally identical to a permission system, often (sloppily) implemented as a flag. Lifetime: as long as the segmentation exists. Owner: product / billing team.

Experiments. Short-lived. A/B tests where the goal is to ship one of the variants and delete the other. Lifetime: hours (a hotfix experiment) to weeks (a proper test). Owner: the experiment owner, typically PM + engineer.

The four kinds need different infrastructure decisions. Release toggles want fast evaluation and don’t need analytics. Operational toggles want low-latency global flips and audit logs. Permission toggles want segmentation by user attributes. Experiments want event tracking and statistical evaluation. One LaunchDarkly account can serve all four, but the processes around each are different.

The default that prevents debt

The single most important rule: every release toggle has a deletion date in the codebase. Not a deletion ticket, not a Notion doc — a comment in the source.

// FLAG: new-checkout-flow
// Type: release
// Created: 2022-09-12
// Delete by: 2022-10-15 (or sooner if 100% rolled out for a week)
// Owner: @mira
if (flags.isEnabled('new-checkout-flow', user)) {
  return renderNewCheckout();
}
return renderOldCheckout();

A weekly cron job greps the codebase for these comments, finds expired ones, and opens issues. That is the entire system. The cron does not need to be smart — it just needs to be loud.

#!/usr/bin/env bash
# flag-cleanup.sh — find release flags past their delete-by date.
set -euo pipefail
TODAY=$(date +%Y-%m-%d)
git grep -nE 'Delete by: [0-9]{4}-[0-9]{2}-[0-9]{2}' \
  | awk -v today="$TODAY" '
      match($0, /Delete by: ([0-9-]+)/, m) {
        if (m[1] < today) print
      }'

Pipe the output to a Slack channel. Two months in, the team has internalized the rhythm: ship a flag, write the comment, delete the flag two weeks later. No flag debt.

The release toggle workflow

A clean release toggle has six steps and lives about two weeks.

  1. Add the flag, default off. Wrap the new code. Old code path still runs.
  2. Deploy. Both code paths now exist in production; the new one is dormant.
  3. Enable for internal users. Test the new path. Bugs caught here are cheap.
  4. Roll out by percentage. 1% → 10% → 50% → 100% over a few days, watching dashboards.
  5. Hold at 100% for a week. Confidence-building period. If something is wrong, you have not yet deleted the old code.
  6. Delete the flag and the old code path. Single PR. Reviewed and shipped within 48 hours of the decision.

Step 6 is the one teams skip. The result is a codebase where every feature has two implementations and the old one is never tested. Discipline around step 6 is what separates teams that ship fast from teams that move fast and break things.

Operational toggles: the on-call’s friend

Different rules. Operational toggles do not get deleted; they get audited.

A good operational toggle has:

  • One responsibility. “Disable webhook delivery.” Not “disable webhooks and notifications and email.”
  • A documented runbook entry. What it does, when to flip it, what to expect downstream.
  • A tested fallback path. If you flip it, the fallback must actually work. Test in staging quarterly.
  • An audit log. Every flip is recorded with who, when, why.
// FLAG: kill-switch-stripe-webhooks
// Type: operational
// Effect: when ON, webhook delivery to Stripe is paused; events queue in DB.
// Runbook: https://internal/runbooks/stripe-webhooks
// Last flip: 2022-08-14 — flipped during Stripe outage, restored same day.
if (flags.isEnabled('kill-switch-stripe-webhooks')) {
  await queueEvent(event);
  return;
}
await deliverWebhook(event);

The runbook link is the difference between a useful kill switch and a tripwire that nobody dares touch. If on-call cannot find the documentation in 30 seconds at 3 a.m., the kill switch is decoration.

Permission toggles want a different shape

If you are using your feature-flag system to express “paid users get this feature,” you are eventually going to regret it. Permissions and flags share an evaluation pattern but diverge sharply on data model.

A permission has:

  • A subject (user, organization, role).
  • A predicate (subscription tier, feature add-on, geo).
  • An audit story (when did Alice’s plan change? Who changed it?).

A flag has none of those — it is a global switch with simple targeting. Implementing permissions as flags works for the first 10 features and breaks at the 50th, when product asks “show me everything Alice can access” and the answer is “grep the code.”

For permission-style decisions, build a thin authorization layer (or use one — Cerbos, Oso, OpenFGA) and reserve the flag system for actual flags. The single place I’ll bend this rule is beta opt-in toggles, where the permission is genuinely “is this user opted into the beta?” — that is shaped enough like a flag to fit.

Experiments: less than you think

An A/B test is a flag plus an event-tracking pipeline plus a statistical evaluator. The flag part is the easy part. Most experiment systems make three mistakes:

Sticky assignment is missing or broken. A user who saw the green button on Tuesday and the red one on Thursday is not in the experiment — they are noise. Bucket on user_id (or a stable cookie for logged-out), and write the assignment to a log table the first time you see it. Subsequent reads use that log, not a recomputation.

SRM (sample ratio mismatch) is not checked. If you assign 50/50 and end up with 47/53 split, the experiment has a bug — usually a filter that drops one variant differently. Always run a chi-square check on the assignment ratios; reject the experiment if SRM is off.

Stop conditions are not pre-registered. “Watch the dashboard until it looks good” is not a methodology. Set the sample size, the metrics, and the decision rule before the experiment starts. Otherwise you are running a guided fishing trip.

The flag system supports the experiment, it does not run it. If you do not have an event pipeline that knows the assignment, you are running a feature flag, not an experiment.

The build-vs-buy decision

For a team under ~20 engineers shipping ~5 flags per quarter, a homegrown system is fine: a config table in your existing database, a simple API to fetch flags by name, in-process caching with a 30-second TTL. About 200 lines of code.

Past that scale, the operational cost of running your own (cache invalidation, audit logs, percentage rollouts that match across services, sticky assignment) starts to exceed the cost of LaunchDarkly / Statsig / Unleash. The break-even is somewhere around 50 flags or 5 simultaneous experiments — at that point, buying gives you the SDKs, the rollout dashboards, and the audit trail for less than what an engineer would charge to maintain the homegrown one.

The mistake is going either direction prematurely. A 5-engineer team buying LaunchDarkly day one is overpaying. A 100-engineer team still on a feature_flags SQL table is paying in incidents.

The metrics worth watching

For the flag system as a whole, a small dashboard answers “is this healthy?”:

  • Total active flags. Should grow more slowly than the codebase.
  • Flags past their delete-by date. Should be trending toward zero. Spike = team is shipping but not cleaning up.
  • Median flag age. Long-tail flags are usually accidental.
  • Flag-evaluation latency p99. A misconfigured SDK can add 100ms to every request. Worth catching.
  • Flag-evaluation error rate. A network hiccup that defaults a flag to “off” can silently break the new feature for an hour.

The “evaluation error rate” metric saves more incidents than it sounds like. Most flag SDKs default to a fallback value if the flag service is unreachable, and your code probably does not handle “fallback” gracefully — the new feature just disappears and somebody on Twitter complains before your alerts fire.

The takeaway

Feature flags are a force multiplier when you treat them as four different tools with four different lifetimes. Release toggles get a delete date in the source. Operational toggles get a runbook. Permissions go in the auth system, not the flag system. Experiments need event tracking and pre-registered stop conditions.

The team that gets this right ships continuously and has 30 active flags. The team that gets it wrong has 300, mostly unowned, and does not know which ones are load-bearing. The difference is not the tooling. It is the discipline of treating each kind as the kind of thing it is.

A note from Yojji

The discipline of “every release toggle gets deleted within two weeks” is the kind of process detail that does not show up in a feature roadmap and decides whether a codebase still ships fast at year three. It is the kind of engineering culture Yojji’s teams build into the products they deliver for clients.

Yojji is an international custom software development company founded in 2016, with teams across Europe, the US, and the UK. They focus on the JavaScript ecosystem (React, Node.js, TypeScript), cloud platforms (AWS, Azure, GCP), and full-cycle product delivery — including the rollout and cleanup processes that decide whether feature flags are an asset or a slow-growing tax.