Feature flags are one of those tools that every team thinks they want until they try to maintain a couple hundred of them. We’ve shipped products using LaunchDarkly, GrowthBook, Unleash, Flagsmith, and a few hand-rolled boolean columns in Postgres. The right answer is “it depends,” but the dependencies are usually predictable.
The three serious options
- Built-in flags — your platform (WRNexus, your auth provider, your in-house admin) already ships a “feature ON/OFF per workspace” primitive. You read it from your code, your admin console toggles it, that’s it.
- Self-hosted open source — Unleash, GrowthBook, Flagsmith, etc. You run a small service that your app SDK queries.
- A flag vendor — LaunchDarkly, Statsig, Optimizely. You pay per seat or per evaluation, and you get experimentation, targeting rules, and a polished UI for non-engineers.
Each is the right answer for a different team. Most products outgrow option 1, plateau happily on option 2, and only need option 3 when they’re doing real statistical experimentation.
When the built-in is enough
If everything you need to express fits this sentence:
“Turn feature X on for this list of workspaces.”
…then your platform’s feature-flag table is enough. WRNexus exposes exactly that primitive:
GET /api/workspaces/{id}/feature-flags
PUT /api/workspaces/{id}/feature-flags/{flag} { "enabled": true }
…and ships an admin UI that lets a support engineer flip it for any workspace, with the change landing in the audit log. For 80% of the launches we do, this is the entire flag system.
When to upgrade to self-hosted OSS
You’ve outgrown the built-in flag when engineers, not just admins, need to roll out a flag — typically with percentage-based rollouts, attribute targeting (“workspaces in the EU only”), or short-lived experiment flags.
At that point the OSS options become attractive because:
- You can run them in the same VPC as your app, so no extra latency.
- You’re not paying per seat or per evaluation.
- The data they hold (flag definitions, evaluation logs) stays inside your perimeter.
The cost is real: an extra service to monitor, upgrade, and back up. For teams of 5+ engineers shipping daily, the cost is paid back quickly. For teams of 2 shipping weekly, it usually isn’t.
When the vendor is worth it
The clearest signal is statistical experimentation: A/B tests with proper p-values, multi-arm bandits, holdout groups. Building that yourself is a year of engineering you almost never want to spend. LaunchDarkly, Statsig, and the like are very good at this.
The second-clearest signal is product-team self-service. If your PM wants to roll out a flag without writing code, paste a Sankey of the funnel into Slack, and undo it 90 minutes later, a vendor’s UI will pay for itself.
Three rules that apply regardless of tool
- Every flag has a sunset date. Write the cleanup ticket the same day you create the flag. Long-lived flags become permanent dead code paths, and every one is a future incident.
- Default to off. A flag that defaults on means a deploy with a forgotten check is a silent rollout. Default off, evaluate at the edge, and the worst case is “feature didn’t ship,” not “feature shipped to everyone.”
- Treat the flag store as a critical dependency. If your evaluation library blocks the request when the flag store is down, your app outage now includes “the flag service hiccupped.” Cache aggressively, fall back to defaults, and never let a flag lookup add user-visible latency.
The path most teams actually walk
We’ve watched this progression more times than we can count:
- Year 0: a boolean column in Postgres. Works fine. Three flags.
- Year 1: a real flag table with workspace scoping. Admin UI in the staff console. Twenty flags. Still working fine.
- Year 2: the team adopts an OSS flag service because PMs want percentage rollouts. Forty flags. Some dead.
- Year 3+: real experimentation needs surface; a vendor gets picked specifically for the stats engine.
If you’re at Year 0 or 1, the built-in WRNexus flags are designed for exactly you. If you’re at Year 2, our docs cover the integration patterns for Unleash and GrowthBook. If you’re at Year 3+, you’re probably going to call your LaunchDarkly rep anyway.
The lesson: don’t buy the tool you’ll need in two years today. Buy the tool you need this quarter, and migrate when the seams start showing.