How do you use feature flags to ship safely (what do you flag, how do you clean up)?

Here’s the quick version I share with teams when we’re ramping up flags: use them to make every deploy reversible, observable, and boring. Small toggles, measured ramps, instant rollback, and a calendar reminder to delete the darn things. 👇

What we flag

• Release toggles for incomplete code paths

• Ops/kill switches (e.g., force_readonly, disable_payments)

• Experiments (A/B/MVT)

• Risky integrations & pricing/entitlements

Rollout

• Cohorts: staff → dogfood → beta → % ramp (1 → 5 → 20 → 50 → 100)

• Progression gates: advance only if SLOs hold and error-budget hit < threshold

• Rollback: one-click off; dark path callable; documented plan

Guardrails

• Defaults off, config turns on

• Timeouts + fallbacks (circuit breaker around flagged code)

• Dependencies: depends_on: billing_v2 && auth_sso

• Fail-closed for security/billing; fail-open for UX

Observability

• Per-variant metrics: error rate, p95/p99, throughput, conversion

• Flag-scoped alerts: errors{flag=on} > 1% for 5m

• Dashboards comparing ON vs OFF; audit logs (who/why/when)

Governance

• Owner per flag, naming: <domain>.<feature>.<purpose>

• Config-as-code via PRs; link to ticket/rollback notes

• Expiry dates + bots/CI nags at T+14/30/60

Cleanup

• Release flags: remove after 7–14 stable days at 100%

• Experiments: merge winner, archive results

• Kill switches: keep; quarterly review

• Enforcement: nightly expired-flag report; CI fails on stale refs

Tooling

• Vendor: LaunchDarkly / Flagsmith / Split

• Standard: OpenFeature

• Homegrown: JSON + S3/Redis + cache + webhooks

Do/Don’t

• Do: keep flags thin, test both paths, document risk/rollback

• Don’t: nest flags, let them live forever, or bundle unrelated changes

“Safe to ship” metric

• Primary: Δ error rate + Δ p95 (ON vs OFF) within budget for ≥30 min

• Secondary: KPI guardrails hold.