Feature Flag

Teams use feature flags to turn on functionality for selected users, accounts or environments. A newly built checkout widget might be enabled for internal testers before a wider rollout. Depending on implementation, the decision can be evaluated on the server or client, and flag rules may combine audience segments, feature status and rollout percentage.

Flags help separate deploying code from releasing a feature, which can reduce rollout risk and simplify a rollback of a problematic capability. They also introduce technical debt: old flags, overlapping conditions and inconsistent environments can make software harder to reason about. A flag should have an owner, a clear purpose and a removal plan once a temporary rollout ends.

A feature flag does not necessarily protect a secret or authorize a user. Client-visible flags are not a replacement for server-side permissions or security controls. The term differs from a SERP feature, which is a search-results presentation element, and from an A/B test, which may use flags as an implementation tool but requires an experiment design.