You built the new dashboard. It works great in staging.
Deploy to production. Immediately, 50 enterprise customers can't see their data.
Roll back. Schedule a meeting. Figure out what went wrong. Try again next week.
What if you could show it to 5 customers first, watch what happens, then expand?
FOUNDATIONAL - Decouple deployment from release. Ship code every day, enable features when ready.
A feature flag is a conditional in your code: if flag is on, show new thing; otherwise, show old thing. The difference from a regular if statement: the flag value comes from a configuration system you can change without deploying code.
This means you can deploy the new checkout on Monday, enable it for 10 internal users on Tuesday, expand to 100 beta customers on Wednesday, and roll it out to everyone on Friday. All without touching the codebase again.
Feature flags separate deployment (putting code on servers) from release (letting users see it). Deploy daily. Release when ready.
Feature flags solve a universal problem: how do you test changes in production without risking everyone?
Wrap new code in a flag check. Flag evaluates user context against rules. Rules can target by user ID, percentage, attribute, or any combination. Change rules without changing code. Instant rollback = flip the flag off.
Adjust the controls below. The user list updates in real-time showing who would see the feature.
Simple on/off for everyone
The simplest form: flag is either on or off globally. Good for kill switches or completed migrations. 'Is the new API enabled?' Yes or no.
Gradual exposure to new features
Enable for X% of users randomly but consistently (same user always gets same experience). Start at 5%, monitor metrics, increase to 25%, 50%, 100%.
Precise control over who sees what
Complex rules: "Enable for users where plan=enterprise AND region=US AND signup_date > 2024-01-01 AND in 25% sample." Full control over targeting.
Product wants to ship a major checkout redesign, but it's risky. Without feature flags, you either deploy to everyone or no one. This flow lets you target 10% of enterprise customers, monitor their experience, and roll back in seconds if something breaks.
Hover over any component to see what it does and why it's neededTap any component to see what it does and why it's needed
Animated lines show direct connections · Hover for detailsTap for details · Click to learn more
You shipped the new checkout six months ago. It's 100% rolled out. The flag is still in the code. Now you have 200 flags, half of which are "always on" and nobody knows which.
Instead: Set expiration dates on flags. When a flag is 100% on for 30 days, remove it. Add flag cleanup to your sprint rituals.
Every single change gets a flag. Now your code is 50% flag checks. Testing is impossible because there are 2^50 possible states. Performance tanks from all the evaluations.
Instead: Flag risky or reversible changes. Bug fixes, refactors, and small changes don't need flags. Reserve flags for features you might need to roll back.
Flag A enables new checkout. Flag B enables Apple Pay in checkout. You turn on B but not A. Users see Apple Pay button that leads nowhere. Or worse, Flag B only makes sense if Flag A is on.
Instead: Document flag dependencies. Better: make flags hierarchical so B can only be on if A is on. Test flag combinations, not just individual flags.
You've learned how to control feature visibility without redeploying. The natural next step is understanding how to run experiments and measure which version performs better.