Feature flags

Feature flags separate deployment from release: ship code dark, enable for cohorts, run experiments, or operate kill switches. Process maturity requires ownership, safe defaults, monitoring, rollback behavior, and cleanup deadlines—not permanent branching in code.

| Flag type | Typical use | |-----------|-------------| | Release | Gradual rollout of new UX | | Experiment | A/B with metric guardrails | | Permission | Entitlement or internal-only | | Operational | Kill switch during incidents |

					if (flags.checkoutV2(user)) {
  return renderCheckoutV2(order);
}
return renderCheckoutV1(order);
// Owner: payments-team; remove by 2025-Q3; metric: checkout_error_rate
				

On interviews: describe flag lifecycle—create, default off, metric dashboards, rollout stages, owner, and removal ticket. Contrast with long-lived `if (false)` branches.

Common pitfalls: no owner; stale flags; client-only flags for security; enabling without rollback plan.

The trade-off is rollout flexibility versus code complexity and flag inventory debt.

Checklist:

• Name owner and removal date per flag.
• Default safe (usually off for risky paths).
• Monitor key metrics during rollout.
• Delete flag and dead code after full adoption.