Feature flag pattern

Gated release

Managing feature flags independently works fine in isolation. But shipping a batch of related features together creates a coordination problem: toggle five flags manually and you introduce timing windows, partial-state exposure, and rollback complexity under pressure.

The gated release pattern adds a single prerequisite flag — a gate — upstream of every feature flag in the batch. Nothing downstream evaluates unless the gate passes. Rather than configuring each flag with broad audience rules upfront, targeting rules are added progressively per phase: developer during the developer phase, internal during internal validation, and so on. This means early-access users only ever see the specific flags that have been explicitly opened for them — not the full batch.

Mental model

Two layers, one lever

The pattern separates two concerns most flag setups conflate: who is eligible for this release, and which specific features they receive.

Gate flag
Controls admission

Answers "is this user eligible?" Add a segment to the gate and that audience immediately flows into every downstream feature flag for evaluation.

Feature flags
Control allocation

Answers "what does this user see?" Rules are added progressively — developer, then internal, then beta, then all. Each phase opens the batch to the next audience without touching flags that aren't ready.

Kill switch
Instant rollback

Remove an audience from the gate and every downstream flag short-circuits simultaneously. No per-flag coordination required under incident pressure.

Evaluation model

How the two layers evaluate

Every user request passes two checkpoints in strict sequence. The gate is absolute — failure here stops everything. Feature flags are conditional — they run only if the gate passes, and the first matching rule wins.

User request Evaluate gate flag does user match any gate rule? pass fail Evaluate each feature flag rules top-to-bottom, first match wins match no match Flag → ON Short-circuit all flags → OFF Fallthrough flag → OFF
Release lifecycle

From setup to GA

A full release cycle has six phases. Setup and wiring happen once. Each rollout phase is a single gate change. The early targeted release is optional. Rollback is a gate change in reverse.

Create gate flag + feature flags feature flags start with all rules off Wire prerequisites set gate as prerequisite on every flag Developer phase verify gate works — developer only skip Early targeted release optional — custom segment per flag Internal validation add internal to gate + all flags Beta rollout add beta to gate + all flags GA rollout add all to gate — everything ships simultaneously Rollback remove audience from gate — full or partial or hold back one flag
Quick reference

Key rules

01The gate is a hard prerequisite. If it fails, no downstream flag evaluates — regardless of that flag's own rules. There is no override path.
02Add targeting rules progressively. Each phase adds the relevant segment to both the gate and every feature flag — developer for the developer phase, internal for internal validation, and so on. Flags start with no rules and open up incrementally.
03Rollout means adding to both gate and flags together. Each Apply button handles both simultaneously — the gate lets the audience in, the flag rules ensure they see the right features. Early targeted releases are the exception: only the targeted flag gets the new rule.
04Rollback means removing from the gate. One change, every flag reverts simultaneously. No hunting through individual flags under pressure.
05Hold-back is the exception. If one flag isn't ready for an audience, remove all from that flag only. The gate still admits that audience; that one flag simply won't serve them.
Interactive simulator

Configure and simulate a release

Name your flags, set targeting rules, and step through each release phase. The live evaluator shows exactly how flag evaluation changes at each stage — toggle simulated user segments to verify who sees what.