Feature flags — runtime configuration that enables or disables features without code deployment — have evolved from a simple boolean toggle into a sophisticated platform for progressive delivery, A/B experimentation, and targeted rollout management. Done well, feature flags eliminate big-bang releases, enable instant kill switches for faulty features, and power continuous experimentation. Done poorly, they accumulate as technical debt and create a maintenance nightmare. This guide covers feature flag best practices, the leading platforms (LaunchDarkly, Unleash, OpenFeature), and the governance model that keeps flag hygiene manageable.
Feature Flag Types
The Four Types of Feature Flags
Pete Hodgson's canonical feature flag taxonomy identifies four types with different lifecycle expectations: (1) Release flags — hide incomplete features during development; short-lived (days to weeks); removed when feature ships to 100%; (2) Experiment flags — A/B test variants; short to medium-lived; removed when winning variant ships; (3) Ops flags — runtime operational controls (circuit breakers, rate limits, kill switches); long-lived; should be kept but documented; (4) Permission flags — feature access by user tier or plan (beta, enterprise only); long-lived; permanent in the codebase. Understanding the type determines the lifecycle expectation and cleanup timeline.
Progressive Rollout Strategies
| Strategy | How | Use Case |
|---|---|---|
| Percentage rollout | Enable for X% of users, gradually increasing | New features; validate at scale before full launch |
| Ring deployment | Employees → internal beta → 1% → 5% → 25% → 100% | Risk-stratified rollout; each ring is a gate |
| Canary release | New version receives X% of traffic; old version Y% | Infrastructure changes; performance validation |
| Targeted by attribute | Enable for users in specific segment (region, plan, cohort) | Geographic testing; plan-gated features; beta users |
| Kill switch | Flag is on for 100%; can be turned off instantly | High-risk features with emergency off switch always available |
Flag debt
The primary feature flag antipattern — flags that were never removed accumulate as conditional complexity in the codebase. Standard practice: every flag gets a removal date at creation; flagged issues in JIRA/Linear; automated alerts when flags exceed their expected lifetime
LaunchDarkly
The enterprise feature flag standard — client SDKs for every language, advanced targeting rules, Experimentation for A/B testing, and Guarded Releases (automatic rollback when error rate spikes). Used by IBM, Atlassian, and thousands of enterprise engineering teams
1ms
Target flag evaluation latency — feature flag evaluation must be fast enough not to add perceptible latency to API responses. Client-side SDK with local evaluation achieves sub-millisecond flag evaluation via cached flag state synced from the management plane
Progressive Delivery in Practice
Standard progressive delivery with LaunchDarkly: (1) Engineer creates flag (default: off); (2) Deploy code with flag — feature inactive for all users; (3) Enable for internal team (targeting: email @company.com); (4) Enable for 1% random users — monitor error rate and conversion; (5) Ramp to 10%, 25%, 50%, 100% with monitoring gates between each step; (6) Remove flag from code within 2 weeks of 100% rollout. Automated: LaunchDarkly Guarded Releases automatically pauses rollout if error rate exceeds baseline threshold during ramp — no manual monitoring required.
A/B Experimentation
Feature flags enable controlled A/B experiments: assign users to control (A) or treatment (B) deterministically by user ID (same user always gets the same variant across sessions). Measure: conversion rate, engagement metric, or revenue per user by variant. Determine statistical significance before declaring a winner (minimum detectable effect, required sample size). LaunchDarkly Experimentation and Statsig provide built-in experiment analysis. Rule: run experiments for a full business cycle (minimum 2 weeks) to account for day-of-week effects before drawing conclusions.
Self-Hosted with Unleash
Unleash is the open-source feature flag platform for teams that need self-hosted deployment — full feature flag management, A/B testing, and SDK support for 20+ languages, deployed in your own infrastructure. Docker:
docker compose up -d with Unleash's official compose file. SDK: npm install unleash-client; const unleash = initialize({url: 'http://unleash:4242', appName: 'app', customHeaders: {Authorization: '*:*.xxxx'}}). Evaluate: if (unleash.isEnabled('my-feature')) {...}. Self-hosted is the right choice for regulated industries (financial services, healthcare) where flag evaluation data (which user ID got which flag) cannot leave your infrastructure.Flag Governance and Cleanup
Prevent flag debt: (1) Create a Linear/Jira ticket for flag removal at the time you create the flag — set due date based on flag type (release: 2–4 weeks post-launch; experiment: 4 weeks post-decision; ops: quarterly review); (2) Add a comment in code:
// FLAG: new-checkout-flow — remove by 2026-05-01 after full rollout. Track: TASK-1234; (3) Monthly automated scan for flags past their removal date; (4) Include "flags removed" as a metric in your technical debt dashboard. Teams that treat flag cleanup as a first-class engineering task maintain codebases with under 20 active flags; teams that don't accumulate hundreds.Feature Flag Platform Implementation
Our DevOps and software development teams implement feature flag platforms and progressive delivery pipelines for enterprise engineering organisations. Book a free advisory session.