How would you describe your feature set or competitive advantage against Unleash? https://www.getunleash.io/

Agreed that LaunchDarkly is incredibly over priced.

Unleash is open source (Apache 2.0 License). Repo: https://github.com/Unleash/unleash .

Growthbook (as mentioned in a sibling comment) is also open source (MIT License). Repo: https://github.com/growthbook/growthbook

Would be interested in knowing the feature differences between the three as they are all Node / Typescript projects

Great points! I think the main differentiation for us is the connection to pricing and billing. Let’s say you have a feature like “how many seats (users) this customer has” it’s not enough to just be able to define it and fetch it where’ve you need it - which is basically what the tools you mentioned will give you. It depends on which pricing tier the customer’s in. Maybe they bought 5 seats but then 2 more as an add on on top of it. Maybe you want to allow them to use more seats, but just bill them accordingly.

Does it make sense?

Do you expect Enrolla to cover the ground that Lago [0] covers, wrt metering and billing? Or would the golden path for a SaaS startup be to integrate both?

For context: we're in the process of evaluating/integrating Lago after several years of writing custom billing logic while figuring out "pricing-market" fit.

[0] http://getlago.com

Yes, we're actually working on supporting metering and billing these days. I think the golden path for a SaaS startup is to have as few products as possible.

Or another yc company Growthbook

Welcome to the party!

We launched https://devcycle.com about a year ago. We're not trying to compete in the self-hosted / on-prem space. Moreso a super simple setup and high flexibility.

Your use case is interesting though, it would definitely fix a lot of headache for people trying to do this via Auth0 directly. Also this just fits in a perfect slot for people starting up a new SaaS platform for sure. Super cool.

Looks good. My friend launched Flagsmith a few years back too -https://github.com/Flagsmith/flagsmith. I have used it on a few of my own projects and it’s been great/easy to integrate

I love flagsmith! I just commented below that I think what makes what we’re doing different is the focus on SaaS and costumer features - so which features are enabled for whom based on the pricing tier they’re at.

Hmm, Flagsmith is also for SaaS and can do different feature flags for different users, so doesn't sound like it's that different.

Is there any unique features Enrolla has that none of the competitors don't? If there isn't, you might want to come up with some, otherwise it'll be a hard sell to sell something newer, less polished and with no unique selling points.

Yeah I know :) I meant that there are some things specific to SaaS that we're trying to solve - like connecting it to pricing and package tiers. So if we have a feature flag called "SAML enabled" its value is based on what pricing tier that specific customer uses.

> like connecting it to pricing and package tiers. So if we have a feature flag called "SAML enabled" its value is based on what pricing tier that specific customer uses.

But that's not a unique feature, it's a fairly basic feature for a "Feature toggle" service to have, you'd be looking for a while if you're trying to find one that doesn't have that.

It goes beyond a feature toggle. Pricing Tiers/Packages tend to consist of more "sophisticated" pricing mechanisms, usually split into Licensed Features (simple toggles like SAML enabled and limits like Seat Count) and Metered Features (either quotes/limits or pay as you go). We're currently working on the metering functionality together with billing systems integration. That's the difference, IMO, from the common Feature Flags solution.

Thanks for the comments; they are much appreciated and help us shape our messaging and understand what's not going through.

I think I get it now, thanks for taking the time to explain :)

Edit: actually thinking about it, I think the "feature flags" wording is what kind of confused me, as it's usually used for developers, infrastructure and product teams to roll out changes, not for deciding what features should/should not be activated in the product because of the pricing/plans.

It's a pattern of ephemeral switches, that are meant to eventually be removed, while what you're doing are "permanent" flags, not meant to be temporary in order to roll out changes without breaking things.

Thanks again; glad to shed some light :)

I totally get you; we're struggling to find the correct wording. As an engineer, I also bump into the "gradual (temporal) rollout" as the first association of "Feature Flags".

What wording would make sense to you now that you understand the vision?

For me, it's that you described it as a LaunchDarkly competitor, which is mainly that "rollout" use case. It makes me expect the features they have, like alerts that a flag is serving the "launched" variation to everyone, and can be ripped out, or code search to see if any references to a flag remain.

I gather you're probably not doing that stuff?

That said, I have LaunchDarkly for feature rollout, an ACL layer for clients to control their own team's permissions, and then custom code to enable features based on a client's package plan. It feels like a lot of conceptual overlap, and a unified solution would be nice.

Yes that’s our long term goal. I don’t like having to adapt 4 different tools to do things which are quite similar.

quick feedback: the HTML title of your home page is "home" so when I bookmark it my bookmark's title is "home" which isn't really useful. It also means you're search results title will probably be "home" which again... not great.

Hi, Where are the docs for production? I have a droplet with DO, and running a basic laravel SaaS project. I want to give this a go, but don't want to spin up another droplet.

I appreciate the willingness to try it! Thanks!

This one may help you: https://docs.enrolla.io/contributing/overview

If it doesn't, feel free to reach out at the community slack: https://join.slack.com/t/enrollacommunity/shared_invite/zt-1...

We can even jump on a call to assist you.

Since it's Node.js and 2023 out there, it would nice to publish performance testing results for a single EC2/VPS instance.

Seems that no-one mentioned my favorite feature flagging + A/B testing open source tool: https://www.growthbook.io/

I'll second GrowthBook. I was able to drop out of a LaunchDarkly subscription that was costing thousands of dollars per month and into a nice, cozy $29 Growthbook plan with zero loss in fidelity, while also increasing capabilities.

Growthbook has a Chrome dev plugin that allows you to simulate feature flags and value changes without having to modify the actual flags and watch the page update in response to the flag changes, which made it not only cheaper than LaunchDarkly, but markedly better to work with.

This sounds fantastic - I never understood why LD is so crazily expensive. Thanks for the rec.

I love growthbook! We’re building a different kind of feature flag framework - one that is for b2b and connects to your billing and pricing systems (because which feature is enabled is connected to what the user paid for).

What's up with those pricing plans? it goes from $0 (3 users) to $80 ($20 per user for 4+ users) per month.

Congrats on launching! Just curious, how does Enrolla compare to Firebase Remote Config?

Thanks! So we want to tie it to pricing and tiers - the value of the feature should depend on which tier the customer's in.

Congrats on the Show!

Looks great! Starred the repo and look forward to seeing how this evolves :D

I know this is a peak HN comment, but I really fail to see the appeal of using a third-party solution for something so basic. In my applications, feature flags are simply controlled via a "tags" field per user and per team. Additionally, each subscription plan has a "tags" field attached to it that is merged with the user and team tags. The logic of how the application behaves in each case is something you have to write yourself either way, so the only thing these third-party applications are doing are managing a list of flags on your behalf the way I see it. I don't see how someone would pay for that and also expose their user information to a third party for something so simple. Maybe I'm missing something?

Most companies are not in the business of building UIs for rule engines, A/B-testing, user segmentation, etc. The value of giving non-engineers the power to roll out features without code changes is worth quite a lot.

(Where I work we recently went from a home-rolled feature flag system similar to what you described to using LaunchDarkly)

Agreed, dynamically serving features based on a database flag is just one part. There's A/B analytics, rolling out to specific user segments, recognizing stale flags etc...

You could always build it all your self, but I guess you could build a lot of things your self...

Beyond that, who's maintaining it? Are you going to be able to deploy these things across every single one of your systems? Your website? Your apps? In conjunction?

I absolutely understand that you could just read somejson from a cdn and call it a day, but at some point someone is going to have to maintain it and become the defacto feature flag person lol

How is using LaunchDarkly home-rolling a feature flag system?

They are saying they started home-rolled and switched to LD

Like the other person wrote we switched from a home-rolled system to LaunchDarkly.

Having had to implement custom billing logic and working in a startup that is still figuring out how to best price & bundle its product, I can see the value of this.

I think this enables non-engineers to define pricing rules and the associated features.

I wonder if this could integrate well with getlago.com (we're looking at integrating that after years which feel partially wasted on implementing custom billing logic)

I'd love your feedback on https://priceops.org

We recently open sourced Tier http://github.com/tierrun/tier which combines metering, entitlements, feature flags and a client side SDK to simplify things.

tier seems interesting when using Stripe. We don’t so I can’t really comment.

100% LD is targeted at product managers, technical account managers, and any other non-developers who want to gate feature rollouts. The devs can just focus on implementing features, flag them, and then forget about it.

That said, LD is an expensive daily pain in my ass, and anything better, or even a little worse but cheaper, than it catches my attention.

We're currently working on metering and billing integration so I'm not sure if such integration makes sense.

Thank you for the reply. If anything, you can learn from the choices Lago made. It's not easy making a metering and billing system that works well enough for the majority of use-cases.

That works great for simple things. how do you tie a specific feature flag to a cross-engineering organization feature that's under rollout with input from multiple projects?

django-waffle is an example of your approach, and worked pretty well in a monolithic environment. But it also exposed multiple issues in coordination in a service oriented environment, which is one reason why O'Reilly went to LaunchDarkly around 2018.

I get it - that's why it's open-source. You can just run it on-prem.

What you suggested gets complex once you want to start making changes to your subscription plans. Let's say you want to experiment with different configurations. You'd then need to remember which customers were signed up with the "old" package configuration and each of the arms of your experiment, for example.

i opened the page and have no idea what i am looking at. good job!

Care to explain more?

Cool spam but I don't think HN is the right place for non-constructive comments that seem to be written just in order for you link to your own products. We're supposed to (https://news.ycombinator.com/newsguidelines.html) have discussions about various things here, not just your own stuff :)

https://news.ycombinator.com/threads?id=necatiozmen

The funniest bit here is that OP is already using Refine.

You're right! https://github.com/enrolla/enrolla/search?q=refine

That makes the spam hilarious and sad! Hilarious because they didn't notice but sad because they didn't even check. The spam could have been a happy "Wow, so cool you're using what we're building" but instead it turned into a generic "Hey please use this thing I made" message.