Quick take: Feature flags separate deployment from release. You can ship code to production and turn it on for 1% of users, then 10%, then everyone — or instantly off if something breaks.
A SaaS company launched a major redesign by merging a six-month branch directly to all users. When conversion dropped, they had to roll back the entire release, losing a day of fixes. Feature flags would have let them expose the redesign to a small segment first and roll back only that segment.
The problem it solves
Big-bang releases are risky. Progressive delivery reduces risk by letting you control exposure and validate behavior with real users before full rollout.
Core concepts
| Concept | What it is |
|---|---|
| Feature flag | A toggle that controls whether a feature is visible. |
| Progressive delivery | Gradually increasing exposure based on metrics. |
| Kill switch | A flag that instantly disables a feature. |
| Targeting | Showing a feature to specific users or segments. |
| Experiment | Using flags to measure impact statistically. |
Architecture
How it works
Code is deployed with the feature off by default. The flag evaluates per user or request. You enable the feature for internal users, then a small percentage, then larger segments. If metrics degrade, the kill switch turns it off instantly.
Feature flags are also useful for A/B testing, entitlements and maintenance modes.
Real-world scenario
The SaaS team used flags for:
- Internal dogfooding of the redesign.
- Canary release to 5% of free users.
- Expansion to 50% after conversion metrics held steady.
- Full rollout after a week of stable data.
- Instant rollback when a payment edge case appeared.
The same code path served all states; only the flag decision changed.
Advantages
- Lower release risk through controlled exposure.
- Faster shipping because code does not need to be perfect to deploy.
- Instant rollback with kill switches.
- A/B testing and personalization support.
Disadvantages
- Flag debt accumulates if old flags are not removed.
- Code complexity from multiple code paths.
- Dependency on a flag service for runtime decisions.
- Misuse can lead to configuration chaos.
When to use it (and when not)
Use feature flags for risky changes, experiments and gradual rollouts. Use them sparingly for simple, low-risk changes.
Do not leave flags in code forever. Do not use flags as a substitute for testing.
Best practices
- Remove flags once a feature is fully released.
- Use a managed flag service for targeting and analytics.
- Track flag state in logs and audits.
- Test both flag states in automated tests.
- Keep flag logic simple and avoid nested flags.
Progressive delivery turns deployment from a scary event into a controlled dial.