LeFever

Thanks! Great questions.

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.

This looks nice! I noticed that you mention logos in the docs but don’t see a way to specify one. Maybe I missed it?

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.

Will definitely reach out. Thanks!

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.

> ironically with totally non-transparent pricing

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.

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.

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

Definitely agree. Ideally you’d be able to extend the search engine list in Safari’s settings but alas.

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!