- Feature Flags used as Configs;
- Configs used as Feature Flags;
- Live Ops, Control Groups, Experiments, Analytics, and more bundled as "extras" to Feature Flags as if they were the right parent term;
I think classical systems/engineering see feature flags as boolean state in some data store, but these PaaS are pushing it as a new thing and struggling with marketing.
I wish they took the gaming companies lesson and started using the term "Live Ops"
If you have good CI/CD practices, an ENV for the environment has what feature is simplest. No new dependencies, change code commit deploy.
Non-tech folks need something else that allows them to switch it on and then off. For a variety of reasons.
These SaaS companies are only valued this much because they charge based on MAUs, not request-based. I prefer PostHog's model. 100M requests/month is ~$2K [*].
[*] I'm not affiliated with PostHog.
There is no way a Feature Flag system is a multi Billion dollar company based on the tech, and if there IS a Saas-pocalypse it's coming for players like LD first.
Same features as all these big guys, EU hosted, and down-to-earth pricing. Even the free tier got me quite far.
I'm unaffiliated btw.
Audience is decided by analytics tool -> Feature flag server maps audience to feature flag value -> Analytics tool tracks its events and includes feature flag value as attribute
Analytics is a much broader set of tooling. It can (and should) report similar things.
Granted we have a whole team supporting just that experimentation platform, but it's pretty cool. They even expose an MCP server for us to have agents do experiment analysis for us using.
if redis_client.get("staging.feature-flag"):
...
I guess their frontend for managing these is 'nice', but at the end of the day it's a static page that sets flags on redis.
The only appealing marketing I've seen in the past three years
I couldnt imagine a lot of teams are debating anymore whether to build their own or use an off the shelf product like this. The former being a straight forward task for an LLM. And the latter being a point of failure/attack for any one want to mess with the core foundations of a product.
Building something, updating it, running it, testing etc. still requires resources and attention. One example for this would be taxis. You pay for the comfort of not having to drive the car, do maintenance, take into account road works, cleaning, etc. and not because you couldn't drive a car yourself. That time you can use instead to focus on your actual business.
The owner at my current gig has multiple times said "software is over" as it being a sort of gravy train of rent seeking. Products are gonna have to offer real / significant value to attract new customers. Maybe even to keep them, too...
This sounds good in theory but - and I speak from experience with a FF system causing a system-wide outage - clients don't care why YOU had an outage, or that it's not immediately your fault, and they really shouldn't have to. The reality is more like you're paying for a dependecy that you can't mitigate.
Given that every FF system comes with a bunch of different mechanisms that prevent your system from being catastrophically impacted in case the provider goes down, its still the fault of the integrating party if you experience an outage due to a FF provider.
Unleash started in 2014 as an internal tool at my company at the time, because we wanted to ship to production continuously without big-bang releases. It's an Open-Source feature flag platform with SDKs for >25 languages.
A few design choices that might be interesting:
- Local evaluation: server-side SDKs fetch the flag config and evaluate in-process, so user data never leaves your app and a flag check is a memory lookup, not a network call.
- Shared Rust engine (Yggdrasil): the evaluation logic is written once in Rust and embedded in the SDKs, so behaviour is the same across languages.
- Unleash Edge: a Rust proxy/cache for frontend and edge clients at scale. (Commercial)
- OpenFeature: supported if you don't want to lock into our SDKs.
if you already are in a platform capture situation, eg. Azure App Configuration or AWS AppConfig where you already integrate with platform tools using the native auth primitives, what is the benefit one can expect from switching to unleash?
Thoughts after about 3 minutes of browsing: OK, this actually makes sense and I see why people would pay for this. The value proposition is definitely there
[1] https://www.getunleash.io/
If you work on a small startup, not worth it... on a Big corp with a lot of bureaucracy? It's worth it I think.
We have tried self-hosting it, but it's always a pain to allocate people on infra to do it, so I gave up and started paying for it for my teams, and they love it.
I haven’t used unleash but it’s pretty clear your characterization is wildly wrong. 30 seconds looking at docs shows it has features for gradual rollouts, A/B testing, experimentaion with analytics, authentication to control available features, and probably a lot more I missed in a quick skim.