You've got 99 feature flags and guess what? That is the problem.
And it's only the beginning.
Now your team has hundreds of developers, designer, and PMs. Your infrastructure is distributed across microservices, edge networks, and experimental AI side quests. Your users? They're accessing your app from a shiny MacBook Pro, or a beat-up 5-year-old Android, or—somehow—the seat-back screen of a Boeing 777 to Frankfurt.
How do you keep it all from breaking? And when it does break—because, let's be real—it will... how do you figure out why?
In this post, we'll walk through 5 can't-miss tools to help you scale your feature flagging operation without losing your sanity. If you're serious about progressive delivery, safe rollouts, and not making your team overly sweaty on each release, this one's for you.
1. Prerequisites: Flags on Flags on Flags
Most modern feature flagging platforms (GrowthBook included) let you target features by audience segments. For example:
- Internal QA testers on desktop in Canada
- Pro users on mobile who've made 5+ orders in the last 3 months
- Beta testers who DM'd your CEO on Twitter
Cool, right?
But what about when one feature depends on another?
Let's say you're prepping your long-awaited 3.0.0 release. It includes:
- New settings UI
- Fresh checkout flow
- Product carousels that aren't garbage
- Dark mode (#1 requested feature)
You want to flip the whole release on with one flag—but keep the ability to turn off any single part if it breaks.
That's where prerequisite flags come in. You create a release-3-0-0
flag, and make each individual feature (settings menu, checkout, etc.) depend on that release flag. This way, no part of the release goes live unless release-3-0-0
is true. If something starts throwing errors? Toggle that one feature off without touching the rest.
How to do it in GrowthBook:
- Create the top-level flag (
release-3-0-0
). - Set it to false in your production environment but true in dev.
- Create a dependent flag like
new-settings-menu
. - Add
release-3-0-0
as a prerequisite. Done.
Setting a prerequisite feature in GrowthBook
release-3-0-0 flag set as a prerequisite for the settings-menu flag
Still curious?
Check out the docs or watch an explainer video with Clippy 📎
2. Simulation & Archetypes: Know What Your Flags Will Do Before They Do It
Here's a real flag rule we've seen (truth be told, it's actually simplified here):
- Kill switch is off
- Account age > 30 days
- Region isn't restricted
- User isn't in an override list
- Country is GB
- A/B test returns true
Yikes. This is already complex—and you know Joey from Marketing has some other targeting they're itching to add.
How do you understand at a glance how this flag will evaluate without feeling like Charlie:
In GrowthBook, Simulation lets you plug in attributes—like country, browser, etc.—and instantly see the flag's result. You'll know before you ship whether a rule will work or explode.
See how features evaluate with simulation
But adding in those attributes time and again becomes tedious fast. Archetypes are a solution to that pain, letting you save common user types (like "internal tester" or "new mobile pro user") and then easily see how any flag is evaluated for them.
💡
Head to SDK Configuration → Archetypes → Simulate to get a bird’s-eye view of all flag evaluations for any given user type.
3. Dev Tools: See What Your Flags Are Up To in the Wild
You've tested internally, you've simulated, and your flag has gone live. But wait—your teammate says they can't see it. There's the ping from QA. And support says users can't find the promised dark mode and if they can't dark mode, what's the point?
Time to start the arduous debugging process...
GrowthBook Dev Tools , a browser extension for Chrome and Firefox, is here to help 💁
With Dev Tools, you can:
- Inspect live flag values in your app
- See experiment variations and why they were assigned
- View current user attributes
- Override values to test different states
- Lots more!
Dev Tools works with most frontend SDKs (just make sure enableDev: true
is set in your config). Support for some backend SDKs coming soon.
See the full walkthrough 📼 to learn more:
4. Staleness Detection: Clean Up Your Crusty Old Flags
You launched a feature 2 months ago. The flag's still in production, but no one knows why. And now it's silently directing 100% of traffic to Variation A ... and nothing else 😐
That's a stale flag , and it's building up tech debt that's sure to cause confusion, bugs, and more work down the line.
GrowthBook detects staleness automatically. If a flag hasn't been touched in a while and is sending all users to the same variant, you'll see a clock icon in the Flags view. (Hover over the icon to learn why it's stale.)
By alerting you to stale flags, GrowthBook helps you keep your features current and your codebase clean.
🧠 More on how staleness detection works
5. Code Refs: Find Your Flags in the Actual Codebase
Your PM wants to delete the new-headline-cta
flag. Is it still used in the frontend? Backend? Nowhere? 🤷
Instead of grepping through every repo, use Code References in GrowthBook.
It shows you:
- Repos and file names
- Line numbers and code snippets
- Links to the exact spot in your code
To enable it:
- Add the GitHub Action (GitLab and other platforms supported, too!)
- Go to Settings → Feature Settings → Code References and enable.
- Make cleaning up flags suck a little bit less.
Wrapping Up
Feature flags are pretty much a necessity for modern software development—but you gotta keep them under control. As your app (and your team) grows, so does the complexity. The tools above will help you stay ahead of it all.
👉 Want to try them out for yourself? Start for free or say hi on Slack.