Feature flags are a superpower for shipping fast. Deploy to production anytime, control who sees what, roll back instantly without a deployment. But without discipline, flags become tech debt — a codebase full of conditional branches that nobody understands.
Here are 7 practices that keep flags useful without letting them take over your codebase.
Use a consistent naming convention
Flag names are how your team communicates about features. A sloppy naming convention leads to confusion, duplicates, and flags that nobody remembers creating.
Recommendation: Use kebab-case with a clear pattern: {scope}-{feature}-{variant}. For example: checkout-new-flow, billing-annual-discount, onboarding-skip-tutorial.
| Good | Avoid |
|---|---|
| checkout-new-flow | newCheckout |
| billing-annual-discount | flag_42 |
| onboarding-skip-tutorial | test123 |
Clean up flags after rollout
The number one mistake teams make with feature flags is never removing them. Every flag adds a conditional branch to your code. After a few months of "we'll clean it up later," you end up with hundreds of flags, half of which are permanently on and nobody knows what they do.
Recommendation: Set a rule: when a flag reaches 100% rollout and has been stable for 2 weeks, remove the flag from your code and archive it in the dashboard. Add flag cleanup to your definition of done.
Use gradual rollouts instead of big-bang releases
The whole point of feature flags is to decouple deployment from release. Use that power. Don't flip a flag to 100% on day one — ramp up gradually.
Recommendation: Start at 5-10% of traffic. Monitor error rates, latency, and user feedback. Ramp to 25%, then 50%, then 100%. If something breaks at any stage, flip the flag off instantly. ToggleTown's percentage-based targeting makes this easy.
Every feature flag needs a kill switch plan
Before you ship a flag-wrapped feature, ask: "What happens if we need to turn this off instantly?" If the answer is "we don't know" or "it would break things," that's a problem.
Recommendation: Design features to degrade gracefully when the flag is off. The old behavior should still work. If turning off a flag would cause data loss, orphaned state, or broken UIs, rethink the implementation before shipping.
Use the right flag type for the job
Not every flag is a boolean on/off switch. Using the right flag type reduces code complexity and makes targeting rules more powerful.
| Type | Use for | Example |
|---|---|---|
| Boolean | Simple feature toggles (show/hide a feature) | new-dashboard → true/false |
| String | Variant selection, themes, A/B copy testing | cta-text → "Start Free" / "Try Now" |
| Number | Thresholds, limits, tuning parameters | max-upload-mb → 10 / 50 / 100 |
| JSON | Complex configuration, multi-field settings | onboarding-config → { steps: [...] } |
Separate operational flags from release flags
Not all flags serve the same purpose. Release flags control feature rollouts. Operational flags control system behavior (rate limits, timeouts, circuit breakers). Mixing them up leads to confusion.
Recommendation: Use naming prefixes to distinguish flag types. For example: release-checkout-v2 for feature rollouts, ops-api-rate-limit for operational tuning, experiment-pricing-page-cta for A/B tests. This makes it easy to filter, audit, and clean up flags by category.
Don't use flags as long-term configuration
Feature flags are meant to be temporary. If a flag has been on for 6 months and nobody plans to turn it off, it's not a flag — it's configuration. Move it to a config file or environment variable where it belongs.
Recommendation: Audit your flags monthly. If a flag has been at 100% for more than 30 days with no plan to remove it, either clean it up (remove the conditional, keep the feature) or migrate it to proper configuration.
TL;DR
- 1Use consistent kebab-case naming with a clear pattern
- 2Clean up flags after full rollout — make it part of your definition of done
- 3Roll out gradually: 5% → 25% → 50% → 100%
- 4Plan for kill switches — features should degrade gracefully
- 5Use the right flag type (boolean, string, number, JSON)
- 6Separate release flags from operational flags with prefixes
- 7Don't use flags as permanent config — audit monthly
Get started
Ready to put these practices into action? ToggleTown gives you feature flags with targeting, percentage rollouts, experiments, and team collaboration — all on a flat-rate plan.
- →Follow the 5-minute Node.js tutorial to set up your first flag
- →Read the docs for SDK guides, targeting rules, and experiments
- →Compare ToggleTown vs LaunchDarkly to see the full feature breakdown