Stripe recently launched an entitlements API [1] that is meant to aid in provisioning and deprovisioning customers, but product integration is not provided (You create subscribe/unsubscribe webhooks and update the entitlements in your own data model, after which you need to build the APIs and functionality to use them). As you alluded, this is actually complementary to Planship, and integration between Stripe features/entitlements and Planship levers/entitlements is something we're considering pending customer feedback.
1. Today, we coexist with entitlement solutions (feature flags, auth systems, etc) by either working alongside them or feeding into entitlement aggregators. Basically, we handle the pricing-related data, logic, and aggregation that eventually reduces down to flags (Or numeric values, lists of items, or other value types). We offer SDKs to make these pricing entitlements easily accessible within a product marketing page, app, etc., but our API can just as easily be used to integrate with other systems.
2. We store complete subscription renewal history but the API for accessing it isn’t public yet. Audit trails, both for customer behavior like you mentioned, as well as admin tasks (E.g. Entitlement value X was added to plan Y) will be available via our API and in our console.
John Bolton and James Bach are the founders of RST [1] and generally big names in the “formal” software testing space. Presumably the testers.ai folks aren’t fans. :p
I’ve been working on a project to make SaaS (and really any software) pricing and packaging easier. Think things like plans, entitlements, dimensions, metering, subscription migrations, onboarding, and experimentation, all completely independent from billing and payment processing solutions. We can integrate with things like Stripe where we’ll mirror products, customers, and subscriptions, but it’s totally optional.
We’re 100% bootstrapped by way of a previous acquisition and just very-soft launched after talking to a lot of folks at companies of all sizes. Seems like most people end up cobbling this stuff together with various levels of sophistication, which is basically what we did a few times over at previous companies with varying levels of success.
Maybe they’ve been added since you looked, but there are two Beecher’s-related cheeses listed for Seattle [1][2]. You have to click the number next to the Seattle dog to see the complete list of dishes that includes them.
And not to pile on, but the Seattle dog is definitely popular and somewhat ubiquitous to the point it’s common to find cream cheese next to the other condiments at backyard barbecues.
I'm actually working on a solution to plan entitlements among other similar functionality right now. While you can get a basic solution set up with feature flags, we've found that the organization and evolution of billing/pricing-related entitlements (E.g. plans, editions, etc.), especially over time, is increasingly complex with lots of requirements in the peripheral. Think things like varying combinations of feature, seats, and usage-based/metered strategies, team subscriptions, plan migrations, one-off enterprise plans, multi-subscription customers (E.g. promotion periods and layered subscriptions), usage aggregation, automated upselling, etc.
As you show in your blog (Nice post btw!), while you can have a flag with a numerical value representing a limit, the infrastructure for tracking usage is left to the business to implement. Imagine instead that you emit usage of that lever to an entitlement service and entitlements based on that usage are updated in real-time, even across teams. Also imagine that you have other entitlements that may be dependent on that entitlement that update as well. In addition, as limits are approached or crossed, you can choose to have soft enforcement (I.e. let them continue, but notify sales to reach out) or hard enforcement and display a prompt to upgrade.
In the spirit of OP's link, we work alongside existing billing solutions rather than try to reinvent the wheel there. We're bootstrapped via a previous successful exit and working with early customers, so if anyone's interested in chatting, even to just geek out on this topic, please reach out: trent at planship.io.
yes, this is needed too. Specifically for real usage based systems, how do we get these limits to apply all the way down to our API rate limits / filters? And how do we output the usage of these things back to the billing system for metering.
Sooo many usage based pricing things out there (ironically with totally non-transparent pricing), but I agree that it doesn't feel like the right solution has been built yet.
Oh man tell me about it. I also think the trend towards metered, pay-as-you-go pricing in general doesn't make sense for many businesses or their customers, but I digress.
Curious if you've thought much on how to distill feature-flag entitlements, service-limit entitlements, role-based entitlements, billing-based entitlements, and so on to a single interface like "Can I [action]?"
Edit: Ha, just saw your reply in a separate thread. Yes, you have thought about it. :) Would be curious to learn more.
1. Some of these are primarily updated in a UI, some are driven from some other system. Flags are customer UI, but Auth is often customer's customer (admins setting RBAC) or derived from SAML Role / etc.
2. There are very different personas / different blast-radiuses for different changes. This means that there should be different interfaces for the creation and administration of the different type of things.
3. Different scales. Dynamic configuration / feature flags are great, but you don't want the rule payload to be GB, which you would have if you tried to store fine grained permissions inside it. Zanzibar is awesome and should be available to more people.
4. It would be best if we could all agree on the names & types of these objects. I think schema files and code-generation are underused.
5. My inclination is that entitlements are just feature flags under the covers, but that there's enough different that a custom UX is warranted.
6. It's easy to add a ton of latency to applications with this stuff. First we spend 50ms getting the user... then we go get the billing for 50ms... then we get the entitlements for 50ms... There are big gains to be had by having this solved holisticaly.
hmu anytime jdwyer at prefab.cloud would love to hear your thoughts.
Some of these immediately resonate. I'd love (4) to be a reality but it's going to be a struggle to get there, not that it isn't worth striving for. And while I agree with (5), the "covers" are often complex/dynamic and where a lot of difficulty in implementation and maintenance occurs (Sorta touched on in (3)). (6) is what got us thinking about this idea of distilling entitlements in the first place.
"Can I [action]?" is the exact question that Zanzibar[0] was designed to answer in a highly performant and scalable way.
With multiple data sources reading and writing to SpiceDB [1] (our OSS implementation of Zanzibar), those questions can further be extended into "Can [subject] [action] on [resource]", which allows for supporting not just permissions, but (as you suggested) feature flags, entitlements, role-based access control and even billing-based entitlements (if the billing system's information is supplied in as relationships or dynamically via caveat context [2]).
As a concrete example, feature flags can be represented as a straightforward permission:
definition user {}
definition featureflag {
relation enabled: user
permission is_enabled = enabled
}
The real power comes into play when different aspects of the system are combined, such as only allowing a feature flag to be enabled if, say, the user also has another permission:
In the above example [3], a feature flag is only enabled for the specific user if they were granted the flag and they are a member of the organization for which the flag was created. While this is somewhat of a constructed example, it demonstrates how combining the models can be used to grant more capabilities.
With caveats [2], these kinds of questions can even depend on dynamic data, such as the time of day, whether the user's account balance is positive, or even be random based on some distribution (to enabled, for example, partial enablement of feature flags)
This is cool! We're just starting to look into this area as we integrate pricing/billing/plan logic and entitlements at scale. Thanks for the example and reminder to read through the Zanzibar white paper.
It’s kinda clever. The people most likely to look at this project are also likely ideal candidates for implementing the library in a new language (Developer, FOSS enthusiast, interested in the project, need the library in a language they’re familiar with that isn’t implemented yet).
Also, the language pills differentiate between those that have been implemented (color logo, dark text, bold) and those that aren’t (grayscale).
Good points. Those pages also contain links to old implementations (Hashids), because a lot of projects still use those and want to be able to find them.
I know we’re really getting into the weeds here, but I’m curious what issues you’re having with iOS Safari and Kagi. I’m using it with both normal and private tabs and it’s working great. There were a series of fixes in the past month to the Kagi app (necessary for Safari integration) that specifically addressed issues with private browsing. Might want to try it again. Good luck!
They’re claiming not to have analyzed comms in the US:
> "This data comprises the encrypted messages of all of the users of Anoms with a few exceptions (e.g., the messages of approximately 15 Anom users in the U.S. sent to any other Anom device are not reviewed by the FBI)," the document reads.
Stripe recently launched an entitlements API [1] that is meant to aid in provisioning and deprovisioning customers, but product integration is not provided (You create subscribe/unsubscribe webhooks and update the entitlements in your own data model, after which you need to build the APIs and functionality to use them). As you alluded, this is actually complementary to Planship, and integration between Stripe features/entitlements and Planship levers/entitlements is something we're considering pending customer feedback.
Thanks for the question!
[1] https://docs.stripe.com/billing/entitlements