Having a limit of in-flight feature flags, means you’re incentivised to clean them up when they’re done (or decide they’re long running features etc), and it can help keep a handle on in progress work.
But mostly, feature flags are a powerful tool—they can hurt as much as they help if you don’t use them right.
Best options:
-----------------
Flagsmith: has UI and can be self-hosted for free (BSD-3 license).
GO Feature Flag: Completely free, but has no UI, although feature flags can be defined in JSON/YAML files checked into Github
Flagd: Completely free, but has no UI.
Statsig: Free plan covers our needs for a year or two. The .Net SDK is lacking, but we can use REST API instead.
Too expensive/cannot self-host: Growthbook
Kameleoon
Split.io
DevCycle
LaunchDarkly
Another thing: Eppo is actually more focused on Experiment (A/B testing) analysis, and we let customers use any feature flag they want. Some clients use an in-house solution; some use Eppo, and many use commercial third-party options. If those systems have issues, our monitoring is often the first to flag it, and those errors are odd, so our clients pretty systematically flag us when that happens. That long explanation to say: I’ve seen a lot of how feature flagging system fail. Several a day, every day, for months. That’s why I can confidently say that Eppo is great, LaunchDarkly is great. Other commercial solutions… I have doubts: they work for basic use cases, but as soon as you have ad blockers, a bad connection, multiple ways to identify users (cookies vs. accounts; same account on mobile vs. desktop browser), or users who know how to edit their cookies, things get bad. In-house solutions (with one exception) also have common oversights.
We talk a lot to experienced engineers who think they can build it —and they can, key patterns are simple— but tricky cases always pop up. I usually ask a few questions to clarify and help them understand what those gotchas are. Senior tech leads aren’t always… keen on thinking, “That’s too hard for me.” So if they push back even lightly, I tend to recommend people to go that way and expect them to come back weeks later, asking tough questions. It’s never lost time: they learn a lot about their own architecture, limits of spinning up new services, passing configuration, design, etc. More importantly, they learned that third parties have relevant experience building this.
do you need a “platform” for feature flags? if you have so many feature flags that you need complex management i think that indicates you need configuration/settings management.
Works great, has every feature we need. We compared with Darkly which was just insanely expensive for what we needed, millions of page hits adds up quickly.
We did have to do the work of adding unleash containers to our infra, but it was not hard at all.
I cannot speak to price / value, but that FF sharing was so useful at simplifying communication between teams and rollouts, which can always get tricky.
Why?
Because it is an open standard by the CNCF, supported by various wellknown SaaS services (some of which are open and can be self-hosted such as flagd) and they provide a set of SDKs which are pretty homogeneous and with support for almost every popular technology/programming language.