Launch HN: RevenueCat (YC S18) – Simple API for Managing In-App Subscriptions
Before starting RevenueCat, Miguel and I worked together at Elevate (https://www.elevateapp.com), Apple’s 2014 App of the Year. Elevate is a brain training app that monetizes with in-app subscriptions. We found that while the subscription model was essential to the business being viable, implementing it was time consuming, complicated, and boring. We needed to see and react to customer level data on LTV, churn, and conversion and it just wasn’t possible without building our own, complex subscription tracking infrastructure.
RevenueCat is an Android, iOS, React Native, and Unity SDK that allows you to get up and running with subscriptions (with all the bells and whistles) in a couple of hours instead of weeks or months. We’ve found and cataloged the nuances and bugs of the platform in-app purchase APIs and wrapped around them to provide a stable and easy to implement API that is consistent on all platforms.
Right now we provide cross-platform status tracking, receipt validation, customer management, and charting for MRR, conversion rate, and more. Our plan is to become a full revenue management platform, so app makers can focus on making their app useful, and we’ll handle making sure it makes money. There are lots of standard monetization strategies (price testing, lifecycle offers, sales, churn prevention, etc.) that most app developers simply don’t have the time to implement and maintain. These things can make a huge difference to revenue (we saw it first hand).
We believe mobile software is undervalued and subscriptions can help. Right now, it’s too hard for developers to do them right. We want to fix that.
I’d love to hear your thoughts, fears, and desires! We’re working on adding more SDKs (Xamarin, Cordova, etc.) Sound off in the comments if there is one you’d like to see. Also, if you have an app that wants to try subscriptions or monetize them better reach out, we can help.
42 comments
[ 3.3 ms ] story [ 99.0 ms ] threadYou are forced to use Apple's in-app purchase APIs which are not very developer friendly (especially for subscriptions) and aren't very complete with regards to metrics.
Also, RevenueCat will be around for 1000 years so I reject the notion of us disappearing. :p Actually, I think about that every day. I had a lot of friends who got burned when Parse shutdown and I plan to avoid that. The way our pricing and costs work, we should never have to shut down the service.
It's my intention to build the company of my life and run the service forever. I hate the idea of a BigCo buying us, shutting down our service, and screwing over all the devs that trusted us. It would have to be a pretty ridiculous amount of money to make me sell out like that (in case you're listening Mark).
I think we just need build trust in the community. That takes time and I accept that.
Obviously I think the benefits of outsourcing your in-app subscriptions to us is well worth it, based on our experience and the engineering time you will be saving, but I might be biased :)
I've grown a lot since the AppLoop days. :)
As far as not losing motivation, I can't prove a negative, so I won't try.
We are not dead if Apple does something to make the system much better, the problem of multi-channel subscription management will still exist for our largest customers.
P.S. Hope L.A. treats you well. I have scooter envy.
I think they did as good a job as could be done shutting it down. But, I think they missed a huge opportunity though. They could have been Firebase. Maybe making money was an issue but I think they could have figured it out eventually.
Parse was very very good for making it easy to prototype apps. However, once apps began to scale, Parse fell apart and was not a suitable technology. They would not have been able to make money because all the big money comes when people have full scale deployments on a platform, and that simply would not have been possible with Parse's shitty-for-scale technology. Again, very awesome tech for rapid prototyping mobile app development ca. 2012 2013..
It wasn't my decision to bet on the technology; it was in place when I was called in to put out the fires. I have a hard-won personal rule not to bet my organization's technical architecture on any tech that hasn't been around for at least 5 years UNLESS it solves a mission-critical pain point / workflow / etc.
I was on the engineering team for another mobile app that did $20M a year in revenue, mostly from in-app subscriptions.. was extremely costly to manage, so seems like you may have a pain point here and a new tech that may be worth betting on. Good luck!
Why should I trust RevenueCat? "Because... They brings that experience to RevenueCat."
Question: How does RevenueCat data integrate with my data pipeline? Seeing all the metrics and charts in your dashboard is great, but if I already have a data solution set up, is there a way to export all the revenue data from RevenueCat into our infrastructure?
Our dashboard is pretty MVP still. It's good but there is a lot we want to do yet.
There are a couple ways you can get the data out of our service.
We have webhooks that are like Apple's server-to-server notifications, but not terrible. We normalize them between Apple and Google and actually provide events that Apple does not (when a user unsubscribes).
Our Grow plan offers an ETL export where we can deliver you daily (or faster) CSV's ready to be loaded into Redshift or to be incorporated into your own ETL.
We also can do event forward and send subscription events as they happen to third party services like Mixpanel, Google Analytics, or Amplitude. So you can track renewal events without users opening their phones.
That made me chuckle. Sounds like event webhooks + ETL exports should cover everything. So far Apple's metrics have not only been very limited, but the fact that we can't relate them to our user data means that they're almost useless. You can't segment by demographics, correlate to the user's history (are people who do X more likely to convert?), you can't even a/b test.
Any company that is on the AppStore and takes themselves seriously needs to know what they're making off each individual user to the penny. If RevenueCat helps with that, then I expect you'll do very well.
Exactly, the ability to tie subscription data to individual users is essential if you want to run a data driven app business. We make that easy.
You should have an interactive price meter where we enter MTR and see the costs per month.
You should also specify if MTR includes or excludes Apple’s cut.
A great inclusion to the service is handling timed hooks to send notifications. Like if a user is about to have their trial expires and have their subscription cancelled, sending a notification to remind them of the trial can be helpful.
The per $1k pricing is only on dollars over the $20k base. We're planning on a adding price meter a la Segment's pricing page, just a matter of javascript-ing it up.
I just pushed a change (30s ago) that adds the platform cut question. We base it pre-platform cut because it incentives us to reduce the platform cut if possible: by getting more subscribers to the 1 year mark, or by getting subscribers on to cheaper platforms (like Stripe.)
And yes, lifecycle campaigns are something we want to get into. Since we're not in the business of push notifications, we'd probably just let you integrate your OneSignal or Braze key and we could send hooks to them so you could trigger whatever kind of custom campaign you wanted.
Best of luck.
The nice thing is that we can leverage our iOS and Android SDKs and things like Flutter are usually a pretty light wrapper. It takes me more time to understand the workflow for building and deploying than the actual implementation.
Totally worth trying it out for Android. In a lot of ways, Android is a bigger pain than iOS on the server side. Feel free to ping me on Intercom or email jacob@revenuecat.com if you want tips on how to implement it.
Any plans to add an SDK for the Microsoft Store?
Our REST API is pretty simple so it's easy for us to add new platforms. We just want to make sure we take the time to understand each one well before supporting them.
Our whole purpose is to reduce complexity so if we create a bad abstraction, we've failed.
I think it's largely been overlooked by the incumbents (Zuora, Aria, Recurly) because of the complexities of the App Store and the relatively small market compared to credit cards. But the market is growing and more companies are going multi-channel, selling on multiple platforms.
Zuora has a really smug post about it that motivates me a lot to eat their lunch. https://www.zuora.com/2015/07/08/dont-give-apple-money-mobil...
I also think it's so early, people are just starting to define the problem and develop the standard techniques. 3 years ago, Apple was much more restrictive about what apps could use subscriptions, now it's basically open season. For non-game apps, this has turned monetization on its head.
So long story short, I'm not sure. Which is why I'm excited to be the first to build something that I think is obviously needed. We will be able to define the category which is exciting (and a little scary.)
p.s. i <3 lambda school, i'd love to attend a student defense someday
Realistically, this fall. I started to check it out a couple weeks ago but we're so busy with our existing SDKs I don't think I'll be able to bang it out super quickly.
Make sure you save your receipts on your server. That will help you either migrate to RevenueCat some day, or build your own system.
[1] https://www.youtube.com/watch?v=lJhHjACjJjA
I'd love to be able to use the same API for web and mobile, with revenue cat just wrapping a conventional payment processor to provide a compatible API surface.