Feature Flags Are More Than On and Off

Foundation 2

The first feature flag most developers meet is a Boolean release switch. The code is deployed, the flag is off, and someone turns it on when the feature is ready.

That is only one use of feature management.

As organizations adopt flags more broadly, the same underlying mechanism begins serving very different purposes. Treating all of them as the same kind of flag makes governance, testing and cleanup harder than they need to be.

1. Release flags

A release flag separates deployment from exposure.

new-checkout

OFF → existing checkout
ON  → new checkout

This kind of flag is usually temporary. Once the new checkout is fully released and the old implementation is removed, the flag should normally disappear too.

A release flag that remains in the code for years is often not a release flag anymore. It has either become a permanent control or simply become debt.

2. Operational flags

An operational flag controls system behavior rather than product availability.

Examples include:

• disable an expensive downstream call
• turn off a nonessential background job
• switch a subsystem into a degraded mode
• disable a risky integration during an incident

fraud-provider-enabled = false

payment flow
   ↓
use approved fallback behavior

These flags may be intentionally long lived. They should be treated more like operational controls than unfinished product code.

3. Experiment flags

An experiment flag does not merely ask whether a feature works. It asks which variation produces a better outcome.

search-ranking

A → current ranking
B → semantic ranking

Measure:
conversion
successful searches
latency
revenue or another outcome

The important addition is measurement. Splitting users 50/50 without trustworthy exposure data and outcome analysis is traffic allocation, not a meaningful experiment.

4. Entitlement flags

An entitlement controls which capability a customer, plan or account is supposed to receive.

advanced-reporting

Enterprise plan → enabled
Basic plan      → disabled

Unlike a temporary release flag, an entitlement may be permanent because the product intentionally supports different capabilities for different customers.

There is an architectural caution here. If entitlements affect billing, contractual rights, authorization, or other critical business rules, a generic feature flag should not casually become the only source of truth. The feature management layer must fit into the organization's broader identity, subscription and authorization model.

5. Dynamic configuration

Feature management systems increasingly support values beyond Boolean decisions.

search-timeout-ms = 2500
recommendation-model = "model-b"
checkout-layout = "compact"

Structured configuration can go further:

{
  "maxRetries": 3,
  "enableFallback": true,
  "timeoutMs": 2500
}

Now the platform is not only deciding whether code runs. It is influencing how deployed code behaves.

This is one reason the market increasingly uses terms such as feature management and runtime configuration rather than feature flags alone.

6. Progressive delivery

Percentage rollout becomes more powerful when it is tied to a deliberate release process.

5%
 ↓
observe
 ↓
25%
 ↓
observe
 ↓
50%
 ↓
observe
 ↓
100%

The process may be manual, scheduled, or automated. More advanced platforms can connect rollout progression to production telemetry so that a regression pauses or stops exposure.

The flag is therefore becoming part of the release control loop:

change
   ↓
limited exposure
   ↓
production signals
   ↓
decision
   ↓
expand, pause or roll back

7. AI and model configuration

AI systems make runtime configuration even more interesting.

An application may need to change:

• which model handles a request
• which prompt version is active
• temperature or another inference parameter
• which users receive a new agent capability
• whether an expensive model is used only for high value requests

assistant-model

80% → model-a
20% → model-b

observe quality, latency and cost

The mechanism resembles an experiment or dynamic configuration. The operational consequences can be larger because model choice may affect cost, latency, safety and answer quality at the same time.

Different flags need different lifecycles

This is the key architectural point.

Type	Typical purpose	Expected lifetime
Release	Separate deployment from exposure	Days or weeks
Operational	Control runtime behavior or degradation	Potentially long lived
Experiment	Compare outcomes	Until the experiment concludes
Entitlement	Represent product capability differences	Often long lived
Dynamic configuration	Tune deployed behavior	Depends on the configuration

If every flag is governed as though it were temporary, permanent operational controls become awkward. If every flag is allowed to live forever, release flags accumulate and the codebase becomes harder to reason about.

The debt is not only dead code

A stale flag creates several forms of cost:

• developers must understand both paths
• tests may need to cover both states
• incidents become harder to reproduce
• observability data gains another dimension
• support teams need to know which customers received which variation
• multiple flags can interact in unexpected combinations

A mature feature management practice therefore has both a creation process and a retirement process.

create
  ↓
owner assigned
  ↓
release or operate
  ↓
measure
  ↓
keep intentionally OR remove

Why this leads to OpenFeature

Once feature management is used across frontend applications, backend services, serverless workloads and mobile applications, another question appears:

Should every application be written directly against the API of whichever feature platform the organization happens to use today?

OpenFeature exists largely because the answer does not have to be yes. The next lesson looks at what it standardizes, what a provider does, and what vendor portability really means in practice.

---

Feature Flags series

← Feature Flags Explained   What Is OpenFeature? →