Feature flags are what turns 'ship in small increments and measure' from advice into something you can actually do, safely, every day.
1Deploying and Releasing Are Different Actions
Without flags, pushing code to production and exposing it to users are the same event — high stakes, hard to reverse quickly. With a flag, code can sit deployed but off, and 'releasing' becomes a separate, controllable, instantly reversible action.
2A Rollout Percentage Is a Lightweight Experiment
The moment a flag creates a group with the feature and a group without it, you have the basic structure of an experiment for free — comparing your predefined success metric between the two groups gives a real, evidence-based answer instead of a guess about whether to expand the rollout.
3Step-by-Step Breakdown
A feature flag separates two things that are normally bundled together: deploying code (getting it onto production servers) and releasing a feature (turning it on for users). Once decoupled, you can deploy safely at any time and control exposure separately, on your own schedule.
A gradual rollout (5% -> 25% -> 100%) turns 'did this break anything' from an all-or-nothing bet into a series of small, cheap checks. If something's wrong, you've only affected a small fraction of users and can turn the flag off instantly — no redeploy, no rollback needed.
What's the main advantage of a gradual, percentage-based rollout over releasing a feature to 100% of users immediately?
- →It makes the feature run faster for users
- →It limits the impact of anything wrong to a small fraction of users, and lets you turn it off instantly without a redeploy if something breaks
- →It's required by most cloud providers
- →It makes the code easier to write
Flags aren't just for safety — pairing a flag with the success metric from your mini-PRD turns a rollout into a real product decision tool: ship to 20%, measure the metric against the other 80%, and let that comparison (not just a gut feeling) decide whether to expand or roll back.
How does pairing a feature flag with a predefined success metric turn a rollout into a decision tool, not just a safety mechanism?
- →It doesn't — flags are purely for safety, not decisions
- →It lets you compare the metric between users who have the feature and users who don't, giving a real, data-based answer to whether the feature should expand
- →It automatically writes the feature's code
- →It only matters for large companies with dedicated data teams
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
Fully supported.
Fully supported.
Fully supported.
Fully supported.
Accessibility (A11y)
1Roll Out Accessibility Fixes Immediately, Not Gradually
Gradual rollout is a great default for new, uncertain features — but a fix for an actual accessibility bug shouldn't sit behind a slow percentage ramp, since that means intentionally leaving some affected users broken longer than necessary. Ship accessibility fixes at 100% as soon as they're verified.
// New, uncertain feature: gradual rollout (5% -> 25% -> 100%)
// Accessibility bug fix: ship at 100% immediately once verifiedSEO Implications
- 1
Target 'feature flags for product decisions' distinct from purely infrastructure-focused feature flag content
Readers here want the product-decision angle (pairing flags with metrics) on top of the more commonly covered deployment-safety angle.
Best Practices
Set a Rollback Threshold Before Turning the Flag On
Decide in advance what result (error rate spike, metric drop beyond X%) would trigger turning the flag back off — deciding this with a clear head before launch is far better than deciding it while already anxiously watching a dashboard after launch.
Frequent Bugs
Leaving old feature flags in the codebase indefinitely after a feature has fully shipped or been fully rolled back, accumulating dead conditional branches.
Treat flag removal as part of the definition of done for a feature rollout — once a flag is permanently at 0% or 100% with no plan to change it, remove the flag and the dead branch it created.
Real-World Examples
Caught at 10%
A new checkout flow was rolled out to 10% of users behind a flag. Conversion rate for that group dropped noticeably within a day — the flag was turned off instantly, affecting only that 10% temporarily, and the bug (a broken discount code field) was fixed and re-rolled out the next day.
flag('new-checkout', rollout: 0.10)
// day 1: conversion_rate(flagged) < conversion_rate(control) -> rollout: 0