Skip to main content

Feature Flags and Remote Config

Feature flags and remote config let teams separate deployment from release. Used well, they reduce risk and improve operational control. Used poorly, they create hidden branches in the product that nobody understands.

Use cases​

Flags and remote config are most useful for:

  • staged rollout
  • emergency kill switches
  • environment-specific behavior
  • experiment cohorts
  • server-directed UX tuning
  • enabling behavior that depends on backend readiness

They are not a substitute for fixing architecture or reducing code coupling.

Flag taxonomy​

Define categories such as:

  • release flags
  • experiment flags
  • operational kill switches
  • entitlement-driven flags
  • long-lived configuration values

Each category should have different lifecycle rules and owners.

Evaluation model​

The team should know:

  • where flag evaluation happens
  • how defaults behave before config loads
  • whether values are cached
  • how stale config is handled
  • whether offline behavior should keep the last known value

Critical flags need safe defaults. A missing config payload should not create undefined product behavior.

Ownership and cleanup​

Every flag should have:

  • an owner
  • a purpose
  • a target removal date or review date
  • a known fallback state

Long-lived abandoned flags are one of the fastest ways to make a codebase unreadable.

Operational design​

For release-critical flags, define:

  • how quickly values propagate
  • who can change them
  • whether changes are audited
  • whether they require peer approval
  • how rollout percentage changes are monitored

Kill switches are only useful if the team trusts that they work under pressure.

Client architecture​

Keep flag access centralized:

  • one client or service layer
  • typed accessors for important flags
  • screen and domain logic consuming normalized values
  • analytics enriched with relevant exposure context

Avoid raw string-based flag lookups sprinkled across components.

Team rule​

Every flag should either be temporary or explicitly promoted into a durable product configuration contract. Anything in between becomes technical debt disguised as flexibility.

Use this with CI/CD and Release Engineering and Offline-First and Sync.