Feature Flags & Experiments
Gate releases, target features to cohorts, run safe rollouts, maintain kill-switches, and optionally run A/B experiments — all without shipping code to toggle behavior.
Options
Flag Backend*
Flag Value Types*
Targeting Model*
Governance Controls
Decision Points
Self-host (Unleash, Flagsmith) or managed (LaunchDarkly, Statsig)?
If yes
Self-host when data-residency, compliance, or flag volume at scale make managed pricing prohibitive. Budget ongoing ops time for the flag server and SDK upgrades.
If no
Managed is the pragmatic default — every feature you need is built in. Pricing becomes painful only above high MAU counts.
Boolean flags only or multivariate (A/B/C payloads)?
If yes
Go multivariate when you need A/B experiments with >2 arms, runtime-tunable config (thresholds, limits), or copy tests. Constrain payload shapes with schema validation.
If no
Boolean-only handles kill-switches, release gates, and entitlements — 80% of flag usage. Add multivariate when you have a concrete need.
Target by user/tenant attributes or percentage rollouts only?
If yes
Attribute-based rules (plan tier, geography, email domain) are required for entitlements and beta cohorts. Combine with percentage rollouts inside a rule for 'enable for enterprise at 10%.'
If no
Percentage-only is the simplest gradual-rollout primitive but can't express 'internal team only' or 'enterprise plan.' You will outgrow it.
Per-environment isolation (dev/staging/prod) or single store?
If yes
Separate flag state per environment — a flag enabled in staging must not leak into prod. Mirror the flag identity across envs so code references the same key everywhere.
If no
Single-store setups force tricks like 'env-as-targeting-attribute' which is fragile and error-prone. Avoid for anything beyond a prototype.
Audit-log every flag change with actor/reason?
If yes
Log actor, timestamp, old value, new value, and a required reason field on every edit. Required for SOC 2 and post-incident analysis. Most managed providers do this by default.
If no
Without audit logs, every flag-related incident starts with "who changed what when" taking 30 minutes to answer. Add audit logging before you need it.
Short-lived release flags vs long-lived kill-switches — tracked separately?
If yes
Tag every flag with its intended lifespan. Release flags auto-alert after 90 days; kill-switches are reviewed quarterly but not expired. The two categories want different governance.
If no
Treating all flags uniformly produces flag debt — release flags that were supposed to be temporary rot in the codebase forever.
Auto-expire stale flags after N days?
If yes
Surface flags older than 90 days in a dashboard and nag their owner. Hard-archive only after two nags with no response — never silently delete, as code may still reference the key.
If no
Manual cleanup is possible at small scale but never happens at large scale. Budget an engineer-week quarterly to prune, or accept the debt.
Local SDK evaluation or server round-trip per check?
If yes
Local evaluation with a streamed rule set is the standard — flag checks are synchronous and cheap. All mature providers support this; avoid any SDK that requires a round-trip per check.
If no
Server round-trip is acceptable for very-low-QPS backends or infrequent checks. Never use it in a hot path or on every request.
Let non-engineers (PMs, support) toggle flags directly?
If yes
Scope roles tightly: PMs can toggle flags tagged 'product,' support can toggle entitlements, nobody edits kill-switches without engineering approval. Pair with audit log.
If no
Engineering-only access is simpler but becomes a bottleneck — every rollout is an engineering ticket. Consider approval workflows instead of total lockout.
Flags double as A/B-test assignment, or keep experiments separate?
If yes
Unifying cuts complexity — one system owns assignment, exposure logging, and analytics. Statsig and LaunchDarkly are built around this. Ensure exposure events get into your analytics pipeline.
If no
Separate experimentation tools (GrowthBook, Optimizely) are fine if you already have strong analytics. Flags stay simple; experiments get proper statistics.
Sticky bucketing so a user's variant never changes mid-experiment?
If yes
Hash the user/tenant ID deterministically and store the assignment on first exposure. Users must not see variant A today and variant B tomorrow — it destroys experiment validity and UX trust.
If no
Non-sticky bucketing invalidates experiment results and produces flickering UX. Don't ship experiments without sticky assignment.
Flag dependencies (B only evaluates if A is on)?
If yes
Useful for compound rollouts — a sub-feature flag that inherits its parent's rollout state. Encode the parent check in the child's targeting rules rather than orchestrating in app code.
If no
Flat flags are easier to reason about. Dependencies can produce confusing 'why is this flag off' debugging sessions.
Approval workflow required for prod flag edits?
If yes
Two-person review on prod flag changes is standard above ~50 engineers or in regulated industries. Always provide an emergency-bypass path for kill-switches with audit after the fact.
If no
Direct edits are fine for small teams. Compensate with strong audit logging and paging on unexpected flag changes.
Emergency kill-switches bypass normal review?
If yes
Kill-switches must be flippable in seconds by a single on-call engineer — any approval requirement makes them useless at 3am. Log the bypass event loudly for next-day review.
If no
Requiring approval on kill-switches defeats the purpose. Don't skip the bypass path.
Per-tenant flag overrides for enterprise customers?
If yes
Targeting rules keyed on tenant ID handle this — no separate override table needed. Flag the tenant's ID in the rule and set the desired variant.
If no
Without per-tenant overrides, enterprise promises ('you'll get feature X next week') are hard to keep. Build the rule-based targeting early.
Tradeoffs
Per-MAU pricing scales with user growth — a surprise cost line item once you cross a free-tier threshold
Added request latency on every evaluated flag — unacceptable for high-QPS paths
Near-zero flag-check latency; propagation of changes is seconds, not milliseconds
Slower rollouts; requires emergency bypass or kill-switches are compromised
Assignment, exposure tracking, and analytics all live in one place — but one outage takes down both releases and experiments
Implementation Examples
Managed feature-flag platform with streaming SDKs, targeting UI, audit logs, and experimentation.
Flags plus experimentation with built-in statistical analysis and exposure-event pipelines.
Open-source self-hosted feature-flag service with enterprise add-ons and mature SDKs.
Open-source (self-hostable) and managed flag service with attribute targeting and segments.
Open-source flags and A/B-testing with warehouse-native analytics (BigQuery, Snowflake, Redshift).