Feature Flags: How to Ship Faster With Less Risk
Feature flags decouple deploy from release, turning scary launches into boring ones. Here's how we use them to ship continuously, roll out gradually, and roll back instantly.
Deploy Is Not Release
The core idea: merge and deploy code continuously, but control who sees a feature with a flag. A bug in a flagged feature affects 1% of users, not 100%, and you turn it off without a redeploy.
Types of Flags
- Release flags: Gate unfinished features in main
- Experiment flags: A/B test variations
- Ops flags: Kill switches for expensive or risky subsystems
- Permission flags: Gate features by plan tier
Gradual Rollouts
- Start at 1% internal, then 5%, 25%, 100%
- Watch error rates and latency at each step
- Automatic rollback if a metric crosses threshold
Keep Flags Clean
The biggest risk is flag debt — hundreds of stale flags nobody dares remove:
- Set an expiry on every release flag
- Track flag ownership
- Schedule regular cleanup sprints to delete dead flags and their branches
Testing With Flags
Test both states of every flag in CI. A feature that works on but crashes off is a landmine waiting for the rollback you'll inevitably need.
The Result
Teams using flags well deploy many times a day with confidence, because a deploy is no longer a release. The blast radius of any change is something you control with a slider, not a prayer.
