A feature flag (also called a feature toggle or feature switch) is a conditional in the code that enables or disables a feature at runtime without deploying new code. The feature is deployed but dark; it is activated by changing a configuration value, not by a release.

// flag read from config or a remote service
if (config_get_bool("new_checkout_flow")) {
    render_new_checkout();
} else {
    render_old_checkout();
}

Progressive rollout: enable the feature for 1% of users, watch metrics, increase to 10%, then 50%, then 100%. This is similar to a Canary release but controlled at the application level rather than the infrastructure level.

Kill switch: if a new feature causes problems in production, disable it instantly by flipping a flag, without rolling back a deployment. This reduces the risk of each release.

Trunk-based development: merge an incomplete feature to main but keep it behind a flag that is off. The code is integrated continuously (CI/CD) without the incomplete feature being visible to users. When it is ready, flip the flag.

A/B testing: send different feature configurations to different user cohorts and measure the effect on metrics. See also A/B testing.

Feature flags accumulate. A flag that was added for a rollout and was never removed is dead code that makes the system harder to reason about. Old flags also interact: if flagA && !flagB conditions become exponentially hard to test. Teams that use feature flags need a hygiene practice of removing flags once a rollout is complete.