Feature Flags

What are feature flags?

A feature flag wraps functionality in a runtime conditional whose value comes from configuration, not code: if flags.enabled("new-checkout", user). The deep idea is separating two events that deployment traditionally fused — deploying code to production and releasing it to users. Code ships dark, then releases gradually: internal users, 1%, 10%, everyone — with a kill switch the whole way.

What flags unlock

Progressive delivery: canary releases by percentage or cohort, watching error rates before expanding — the single biggest reducer of change risk in modern delivery (and the mechanism behind trunk-based development, since unfinished work merges safely behind flags). Instant rollback: flipping a flag takes seconds; redeploying takes minutes-to-hours — during an incident that difference is the incident. Experimentation: A/B tests become flag variations plus metrics. Operational toggles: load-shedding switches that turn off expensive features (recommendations, LLM-powered search) under duress.

The debt everyone accumulates

Every flag is a fork in your codebase’s behavior space. Ten boolean flags is theoretically 1,024 configurations; nobody tests them all. Stale flags — released 100% months ago, conditional still in code — are pure hazard: the infamous Knight Capital collapse ($460M in 45 minutes) involved dead-code reactivation via configuration. Discipline that works: expiry dates on every flag, ownership metadata, and flag-removal treated as part of feature completion, not optional cleanup.

What people get wrong

• Building it yourself past the trivial stage — percentage rollouts, cohorting, and audit logs are why LaunchDarkly/Unleash/OpenFeature exist.
• Flags without metrics: a canary you aren’t measuring is just a slow full rollout.
• Config changes without change control — a flag flip is a production deploy; log it, review it, alert on it like one.

Primary source: Martin Fowler — Feature Toggles