Foundation 1

A feature flag is easiest to understand as a decision the application can make at runtime.

if (newCheckoutEnabled) {
  useNewCheckout();
} else {
  useCurrentCheckout();
}

The new checkout code may already be deployed to production. The flag decides whether a particular request, user, account, device, or environment should see it.

That distinction is the reason feature flags matter.

Deployment and release are not the same thing

Without a feature flag, deployment and release often happen together:

build code
   ↓
deploy code
   ↓
users immediately receive the new behavior

With a flag, those two events can be separated:

build code
   ↓
deploy code with flag OFF
   ↓
verify production environment
   ↓
turn flag ON for selected exposure
   ↓
expand when confidence grows

The deployment moves software into the environment. The release changes who experiences the behavior.

A flag can answer more than yes or no

The first mental model is Boolean:

new-search = true
new-search = false

Real feature management systems can make the decision from context. A rollout might be enabled for employees, a beta group, one customer account, one region, or a percentage of traffic.

new-search
   │
   ├─ employees → ON
   ├─ beta customers → ON
   ├─ everyone else → 10%
   └─ unsupported app versions → OFF

That is still one logical feature decision. The evaluation rules determine which variation applies.

Why percentage rollout is useful

Suppose a team has completed a major search change. A traditional release could expose it to every user at once. A progressive rollout might look like this:

0% → 5% → 25% → 50% → 100%

At each stage, the team can observe errors, latency, support signals and business outcomes before expanding exposure.

The percentage itself does not make a release safe. The safety comes from combining controlled exposure with useful observation and a clear decision about what should happen if the change performs badly.

A flag can also act as a kill switch

Some flags exist primarily to reduce operational risk.

Imagine an application depends on an expensive recommendation engine. If that dependency begins failing badly, an operational flag could disable recommendations while preserving the rest of the application.

recommendations-enabled = false

Application continues
Recommendation path is bypassed

This can be faster than building and deploying an emergency code change. It also means the flag itself becomes operationally important and needs appropriate permissions, auditability and failure behavior.

Where does the value come from?

Feature flags are useful because they introduce a controlled decision point between deployed code and exposed behavior.

Teams commonly use that decision point to:

  • deploy unfinished work without exposing it broadly
  • release gradually instead of all at once
  • enable a feature for internal users or beta customers first
  • run controlled experiments
  • disable risky behavior during an incident
  • manage legitimate differences between customer plans or capabilities

What happens when the feature flag system is unavailable?

This is one of the first questions developers should ask, even though beginner explanations often skip it.

The application should not blindly assume that a remote flag service will always be reachable. Mature SDKs usually cache configuration and evaluate locally where possible. Application code should also supply a sensible default.

enabled = getBooleanValue(
  "new-checkout",
  false
)

Here, false is not decorative. It expresses the fallback behavior if the flag cannot be resolved.

Choosing the default is an architectural decision. A cosmetic feature might safely fail open. A sensitive capability may need to fail closed. An operational kill switch needs careful thought because the safest state during a control plane outage may differ from the normal state.

A feature flag is not a security boundary

A client side flag can control what a user sees, but it should not be treated as authorization.

If a browser hides an administrative button because a flag is off, the backend must still enforce whether the user is allowed to perform the administrative action. Anyone can inspect browser code and network traffic.

Feature management can influence experience. Authorization must enforce access.

The small switch creates real complexity

Every Boolean flag can create two possible behavioral paths:

OFF path
ON path

Add several interacting flags and the number of possible combinations can grow quickly. That affects testing, debugging, observability and support.

This is why temporary release flags should usually have an owner and an expected removal point. Once a rollout reaches 100% and the old behavior is no longer needed, leaving the flag in place preserves complexity without preserving much value.

The useful mental model

Do not think of a feature flag as a magical switch in a dashboard. Think of it as a runtime policy decision placed inside the application.

context
   ↓
flag evaluation
   ↓
variation
   ↓
application behavior

The dashboard, SDK, targeting rules and rollout controls exist to manage that decision safely.

The next lesson goes beyond the Boolean switch and looks at the different jobs organizations expect feature management to perform.

Feature Flags series

← Series overview   Feature Flags Are More Than On and Off →