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.
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.
