Hacker News Reader

Comment by heipei | Hacker News Reader

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?

View on HN

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)

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.

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.

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.

Reply on news.ycombinator.com