Deploying code and releasing a feature to users are two genuinely different events, and conflating them is one of the more common sources of deployment risk — feature flags exist specifically to separate the two, so code can ship to production dark, then get released independently, gradually, and reversibly.
Feature flags (feature toggles) are a technique for wrapping code paths in conditional checks that can be turned on or off — often per-user, per-percentage, or per-environment — without a new deployment. This decouples deploying code from releasing a feature to users, enabling gradual rollouts, A/B testing, kill switches, and trunk-based development without long-lived feature branches.
Why Feature Flags Matter (and When to Skip Them)
Deploying and releasing as separate events changes the risk profile of shipping software substantially — a bad feature can be turned off instantly via a flag flip rather than requiring a rollback deployment, and a risky feature can be rolled out to 1% of users before 100%, catching problems at small blast radius instead of full exposure.
Skip a full feature flag system for a small application or team where the coordination benefit doesn't apply, or use flags sparingly — every flag is a form of conditional complexity in your codebase, and unmanaged flag proliferation creates its own maintenance burden that needs to be actively managed, not just accepted as a permanent cost.
Getting Started with Feature Flags
A minimal flag check pattern:
if (await flags.isEnabled("new-checkout-flow", { userId: user.id })) {
return renderNewCheckout();
}
return renderLegacyCheckout();
Percentage-based rollout, common for gradual releases:
const flags = {
"new-checkout-flow": { rolloutPercentage: 10 },
};
function isEnabled(flagKey: string, userId: string): boolean {
const hash = hashUserId(userId, flagKey);
return hash % 100 < flags[flagKey].rolloutPercentage;
}
Core Feature Flags Concepts Every Developer Should Know
Flags serve multiple distinct purposes, and conflating them causes problems. Release flags (gradually rolling out a new feature) are typically short-lived and removed after full rollout. Ops flags (kill switches for risky functionality) may be long-lived. Experiment flags (A/B tests) are tied to a specific experiment's duration. Permission flags (entitlements per user tier) are often permanent. Treating all flags the same way leads to poor lifecycle management.
Stale flags accumulate as technical debt if not actively cleaned up. A release flag that's been at 100% rollout for six months is pure clutter — every flag check is a branch in your code that needs to be understood and tested, and flags that have served their purpose should be removed, not left indefinitely "just in case."
Flag evaluation should be fast and reliable, since it typically sits in a hot path (every request, every render). Most production flag systems cache flag configuration locally rather than making a network call per evaluation, falling back to a safe default if the flag service is unreachable.
Consistent user bucketing matters for percentage rollouts and experiments. The same user should consistently get the same flag value across requests (usually via a deterministic hash of user ID + flag key), not a random result on every evaluation — inconsistent bucketing breaks both user experience and experiment validity.
Common Feature Flags Mistakes and How to Fix Them
Mistake 1: never removing flags after a feature is fully rolled out, letting dead conditional branches accumulate indefinitely. Fix: treat flag removal as part of the feature's definition of done, not an optional cleanup task — schedule and track flag removal explicitly.
Mistake 2: not having a safe default/fallback when the flag service is unreachable, causing an outage in the flag provider to break your application. Fix: cache flag values locally and define explicit fallback behavior (fail open or fail closed, deliberately chosen per flag) for flag service unavailability.
Mistake 3: excessive nesting of multiple flags creating combinatorially many, mostly untested code paths. Fix: keep flag interactions simple and intentional, and test the realistic combinations that will actually occur in production rather than assuming untested combinations won't matter.
When Should You Use Feature Flags Instead of Feature Branches?
Use feature flags for trunk-based development where you want to merge incomplete work continuously without exposing it to users, and for any feature that benefits from gradual, reversible rollout. Use feature branches (without flags) for isolated, short-lived work that doesn't need gradual rollout or a kill switch, and doesn't benefit from the risk-mitigation flags provide.
Feature Flags in Production
Actively track and remove stale flags as a routine practice, not an occasional cleanup sprint — flag debt compounds quietly and is easy to deprioritize indefinitely. Also define explicit fallback behavior for flag service unavailability per flag, since "fail open" and "fail closed" have very different risk implications depending on what the flag controls.
If your team currently ships risky changes as all-or-nothing deployments with rollback as the only mitigation, feature flags are a direct, well-established way to reduce that risk through gradual, reversible rollout instead.