RevenueCat CEO checking in

Hi Jacob. If in the next version of your SDK you could reduce my churn from 16% to 10% that would be great. Should be easy enough.

I was actually thinking of emailing you yesterday, so I’m glad you posted this.

RevenueCat is very close to being one of those unicorn apps that just magically removes an entire subset of problems for businesses. I’m an engineer and CEO of a few software businesses and have done technology consulting for hundreds of others, so there are some things I’d strongly urge you to consider in order to round-out what RevenueCat is doing to consume the rest of the “problem.”

The problem, of course, is that in-app subscription management is a gigantically stupid pain in the ass, precisely multiplied by the number of platforms you need to support. We all want subscription management to be as close to “press a button and it’s all done” as possible and RevenueCat is getting rather close to that.

1. There needs to be a subscription expiration notification.

This is a small hole but a big oversight. I understand the RevenueCat webhook system is designed to mimic the app stores’ webhooks, but the app store webhook logic is horrible. Generally speaking, businesses want to know when to give the goodies, and when to take the goodies away. Just tell us, please. Notify on entitlement activation and deactivation — or some equivalent.

Right now you have to build your own polling system to figure out when to expire entitlements. This is super silly. RevenueCat is already 98% of the way to removing this chunk of work.

2. Design a best-practice backend and really highlight it.

Almost every business needs the identical backend purchase logic, and then they add their own business logic on top of it. There are many SDK examples and backend examples spread around the docs and GitHub, but there should be a simple best-practice systems tutorial as part of the onboarding process.

It takes awhile to figure out the best practice is to essentially build a backend webhook processor, configure it in RevenueCat then build a sync function that triggers on any IAP or those backend webhooks. That’s a really great systems design but it’s not fully spelled out anywhere. It should be!

3. Consider adding a web SDK (and secondarily, web support to the Flutter SDK.)

Web SDK is kind of a no brainer. It’s also common practice to build a Flutter mobile app using RevenueCat and then adding a web version later. If you do this, you’re in for some hurt, because the Flutter SDK doesn’t work when you do that. As a result, you end up with 2 implementations: use the RevenueCat SDK in your mobile apps, and then write your own RevenueCat web SDK for your web app. This is a bit silly and it seems like adding a web SDK and then expanding the Flutter SDK to use the web implementation you wrote could be a good strategy on a number of levels.

4. Keep moving towards simple and intuitive! The recent SDK changes to logIn() and logOut() are perfect examples.

This was a small but excellent move. Keep it up!

I hope this is at least somewhat helpful towards the kind of feedback you’re looking for.

Thanks Jacob for all of your work!