Hmm, after 5 minutes of browsing I still don't get it.

likewise this feels almost like a planted comment without any explanation. It's a get endpoint hosting some boolean fields.

It’s bad form to accuse people of being shills.

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.

Which doesn't really explain why all the comments of the OP/author are flagged and dead... competition at work?

[delayed]

Huh? Is this a new policy? What's your source for this ?

[delayed]

Thanks, "I could build that" → "oh, that's what the other 90% is" is pretty much how Unleash started for us too. What does your homegrown version do? Always interested in where people draw the line between building and adopting.

Great comeback!

Just basically various means of turning features on/off based on static rules. Settings mostly but occasionally user based or URL params.

Your platform has that and a ton of other things that would be useful for larger platforms, but it would be a pain to develop when you're already building a complicated roadmap.

If it's settings, its better off being in your apps settings rather than implemented as a long running feature flag.

Feature flags are meant to be temporary.

Well, I mean.. settings can also be temporary. Could be constants or from the DB, etc.

Perfect candidate for a FF if it really is temporary. I have my own personal rule. If the FF lives beyond a certain amount of time, it gets turned into a setting.

End of the day it seems like only semantics. Feature-flag and a boolean "setting" to enable a feature are the same thing.

At $lastJob$ we had a home-grown solution. My contribution was a simple expression language that created an algebra of flags. Things like `(A | B) && C` or `from: 2027-01-01 && to: 2027-12-31` and so forth. The idea was to enable PMs to do a lot of the feature management directly, and then to use the patterns that arise organically to discover what we would need when we were ready to pay for a SaaS solution.

If you have any questions about what this unlocked for us... Or anything else... "My obfuscated email is in my bio." Happy to help anyone trying to make shipping easier for teams, I self-identify as a toolsmith.

I pay for it for my team... it's expensive to be honest, but worth it IMHO. Building it would be a pain, supporting it even more so.

We have tried selfhosting it, but it's always a pain to allocate people on infra to do it, so I gave up and started paying for my teams on my on budget and it's been super worth it.

From the infra side, it’s something I don’t think makes a lot of sense to self-host. Metrics are the other notable one here.

They have non-linear scaling complexity, so they work fine with bumping up resources until they don’t and now you’re looking at queueing metrics on Kafka or something equally complicated. They’re horrible to change out because a lot of the APIs aren’t compatible and literally everything uses them.

They’re also awful to maintain. Everything uses them so there’s never a window when it’s convenient to shut down the feature flag system for upgrades or to test backup restores. People are much more accepting of “the vendor will be down for 2 hours on Saturday” than “I’m taking the system down for 2 hours on Saturday”.

I'm not sure which provider you are paying for metrics, that you think has acceptable pricing.

We are on ~400k series, and switching to any hosted provider would instantly make that our single biggest infrastructure expense.

Instead we're self-hosting with less than $100/month for hosting and ~less than a hour per month of maintenance with Victoriametrics (have also switched fron singe-node to cluster over time), and it's a breeze.

[delayed]

Regarding number two, that's what I designed featureflip to handle. It tracks dead flags and will submit a pull request to your repository to remove it for you. That's always been a big pain point of mine with launch darkly.

Feels like something that should be a solved problem though.

Part of my last job was winnowing down a convoluted feature toggle system, rebuilding parts of it on top of a FOSS library that did a fraction of the same work. It had become convoluted enough though that it was materially affecting both our deployment time and our cluster density.

To be a little fair to the original author, despite not really respecting him, I had to file a couple serious PRs upstream to simplify the most tortured parts. He worked around a couple of bug/misfeatures but took the scenic route to do it. Guy “never met an abstraction he didn’t like” is not true because his favorite thing was replacing one abstraction with three. And he was one of those guys who learned big words all from books and so he used definitions nobody under 65 has ever used in conversation.

I thought LLMs were supposed to be the death knell for services like this, since you could replicate them and maintain your own code-base with little effort?

At least that's what the AI boosters keep saying.

Lots of tools work like that: You can get to 80% of the value with 20% of the work. I kid, it's even better than that! Sometimes, 80% of the value comes from 2% of the effort to build what they built.

But over time, you realize that half of the remaining 20% matters to you, and it turns out that the remaining 10% you care about is harder than it seems, and until you have it doing everything you need, you're stuck with an ad hoc, informally-specified, bug-ridden, slow implementation of half of LaunchDarkly.

————

Personally, I have worked on an in-house feature flag system, and I told everyone who would listen that its purpose was needs validation, and that as soon ass we were 100% sure we knew EXACTLY what we needed, we could go shopping. And that was in the hand-written code era. Today, you could vibe an 80% solution and do your needs assessment from there.