Congrats on the launch. I love 'boring infrastructure' companies, they are the ones that become huge :) The world is moving to subscription businesses and the tech needs to catch up

Man I wish this existed 8 months ago when I built our own version internally! We have a mix of Stripe and App Store customers so we'll definitely be switching (to remove our mental load) if you guys ever support that!

Best of luck.

Stripe is coming! This was a big source of pain for us at Elevate, supporting 3 platforms seamlessly.

Product looks great and would love to use it for iOS+Stripe, so I have to ask - any timeline for Stripe integration? Also this Fall?

Stripe might be sooner since it's mostly just backend work and we have some existing customers asking for it.

Any plan for a Flutter SDK?

Right now I'm handling the iOS, Android, React Native, and Unity and its a full time thing. I'd like to add more SDKs as soon as we can.

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.

Pricing isn’t clear for larger scale apps. Is the extra charge per $1k on include the first 20k; after a tier is reached, how is the next $1k calculated.

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.

Great feedback. Thank you.

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.

About time. It just saddens me that after so long dealing with the myriad problems of selling through the AppStore, the response has to come from a third party instead of Apple. Well, I guess it's developers solving developers' problems.

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?

We feel your pain. In fact we felt it so bad we decided to fix it. :)

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.

> We have webhooks that are like Apple's server-to-server notifications, but not terrible.

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.

You should come with me when I pitch investors.

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.

This looks amazing and is definitely much-needed.

Any plans to add an SDK for the Microsoft Store?

We want to have an SDK for every platform on Earth...eventually.

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.

Any ETA/plans for a web version?

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.

Soooooon. :)

Why has this not existed before?

That is a great question.

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

Thanks, we'd love to have you! Finish up demo day and fundraise first :)

Why would I use this over, say, Stripe, which is also very developer friendly, robust, and no fear of disappearing anytime soon.

If you are selling digital goods on the app store, you can't use credit cards (and therefore Stripe).

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

My experience getting burned by Parse was when the platform was up, it was a flaming pile of shit. Erratic errors, inconsistent downtime, terrible support. The only good thing was the shutdown, IIRC they offered phenomenal support thanks to having the resources of Facebook - 1 year notice, open source software to ease the transition, etc.

This is an excellent, if a little macabre, take on the Parse shutdown.

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.

Thanks for the compliment on my macabre take.

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!

What if Mark acquires you?

I will only sell to Megaupload.

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 believe that you truly hold this attitude now, but your response could literally be the preface for every "our incredible journey" post ever published.

Yeah, that's why this objection is pretty frustrating. No one will really believe me anyway so I don't get too worked up trying to convince people.

I think we just need build trust in the community. That takes time and I accept that.

Hi – Miguel here. That is totally valid point. I also think this objection stands true for every dependency of your technical infrastructure. This is the kind of decision you have to make, assessing the risks on a case by case basis. I believe no dependency is 100% safe. It can happen to any given service, from companies like Heroku, MixPanel or Segment to the smallest open source library you rely on.

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

Hi Jacob :) Good to see you still building things. I love your optimism but this is something I've heard countless times that almost never holds true. Truth is you eventually get bored of a product after a few years and move on. It's not even always about the money. Also, you're playing in space where Apple could build their own and Sherlock you. I know a thing or two about that.

Hi Shane!

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.

Typo :^)

Why should I trust RevenueCat? "Because... They brings that experience to RevenueCat."

Oh! On our web page. Good catch!

Sounds cool. I would deploy it for our iOS app, but our subscriptions are finally working really well and there is too much risk that we’d break it. Maybe we’ll try it for our Android version when that gets built in a few months.

Yeah, that's an understandable objection. We need to work on our value prop for customers who already have systems deployed. The switching costs aren't that bad, but there's a question of "why wake a sleeping monster" by messing with it.

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.

When will the Xamarin SDK be ready? Need to decide whether to implement on our own or wait for RevenueCat

2 weeks! [1] jk

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 guess we'll just make do until the Xamarin SDK is ready. Thanks.

Yeah, sorry. You aren't the first to ask and I suspect not the last. We're gonna do it.

There's a minor typo in the footer: "Revenue Model Cal>C<ulator"

Thanks!