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.
Thanks for the comments; they are much appreciated and help us shape our messaging and understand what's not going through.
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?
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.