[capableweb]

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.

[GalKlm]

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?

[satyrnein]

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.

[nirga]

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