A feature flag makes selected behavior conditional at runtime rather than requiring a new build for every exposure change.

This can separate deployment from release. New code may already be running in production while the feature remains disabled, enabled only for internal users, or exposed gradually to a subset of traffic.

Flags are useful for staged rollout and rapid disabling of risky behavior, but they add another dimension of system state. Both enabled and disabled paths may need testing while the flag exists.

A flag intended for temporary rollout should have an owner and a removal condition. Leaving old flags indefinitely creates combinations that are difficult to reason about and can hide dead code.

Feature flags are not authorization controls unless designed and enforced as such. A user-facing toggle that can be bypassed must not be treated as a security boundary.

Used deliberately, flags reduce release coordination; unmanaged, they become long-lived conditional complexity.