Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Show HN: We built an open-source LaunchDarkly alternative for B2Bs

enrolla.io

Post reply on HN
Print view View original

21–30 of 53 posts

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#21

Post by capableweb »

GalKlm wrote: post #20
capableweb wrote: post #18

Earlier quoted context omitted.

> 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 Fe…

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.

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#22

Post by GalKlm »

capableweb wrote: post #21
GalKlm wrote: post #20

Earlier quoted context omitted.

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 Fe…

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 even…

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?

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#23

Post by heipei »

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?

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#24

Post by andruby »

heipei wrote: post #23

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 wr…

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)

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#25

Post by nirga »

heipei wrote: post #23

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 wr…

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.

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#26

Post by andruby »

nirga wrote: post #8
parkerhiggins wrote: post #2

How would you describe your feature set or competitive advantage against Unleash? https://www.getunleash.io/ Agreed that LaunchDarkly is incredibly over priced.

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…

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

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#27

Post by nirga »

andruby wrote: post #24
heipei wrote: post #23

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 wr…

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…

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

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#28

Post by satyrnein »

GalKlm wrote: post #22
capableweb wrote: post #21

Earlier quoted context omitted.

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 even…

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.

Re: Show HN: We built an open-source LaunchDarkly alternative for B2Bs

#30

Post by TrickyRick »

heipei wrote: post #23

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 wr…

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)

Post reply on HN