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

Feature Flags as a Deployment Decoupling Mechanism

The core value of feature flags is decoupling code deployment from feature release: new code can be merged and deployed to production behind a flag that’s initially off, letting teams ship incrementally and reduce the risk of large, infrequent releases, then enable the feature for users independently of any deployment event, often through a runtime configuration change rather than a new code deploy. This decoupling also enables gradual rollouts (enabling a feature for 5% of users, then 25%, then 100%, monitoring for problems at each stage) and instant rollback (disabling a flag is far faster than reverting and redeploying code), which is why feature flag platforms have become a standard part of the deployment toolchain at organizations practicing continuous delivery, particularly those releasing to production many times per day.