My chat with Jacob Eiting, Cofounder & CEO of RevenueCat

There’s a lot of chatter these days about Apple’s in-app purchase system. There’s regulatory scrutiny on Apple’s in-app purchase system worldwide. I wanted to get the perspective of someone who is not an iOS app developer but has a direct stake in how this battle shakes out because of their role in the developer ecosystem. I talked to Jacob Eiting, Cofounder & CEO of RevenueCat, a subscription management platform for developers building across iOS, Android, and Web. I’m supposed to have a serious reason, so I said what I said in this intro. In reality, it was just his funny tweets that made me want to reach out.

Jacob: So why did you pick me to talk to? 

Sar: You have this fun shitposting personality on Twitter, and how could I not pick a shitposter? You recently tweeted, "come work with me on growth. If the growth lead doesn't sound right to you, I'm open to the growth chairman or the director making numbers bigger".

Jacob: Nobody took me up on that. 

Sar: Another one was, "should RevenueCat have a cat?"

Jacob: I've stopped making any of my own decisions. I'm purely leading by Twitter democracy at this point. I'm on an SEO crusade right now, and I was tweeting the other day to get keyword generation from my followers. And it was insightful. You shitpost like 80% of the time to gain a following, and then you can extract value in that last 20%. 

Sar: One of my favorites was "how does Looker not yet have a copy to Google Sheets one-click thing? I was promised synergy." 

Jacob: Yeah. That one didn't do that many numbers. The problem is I would have more followers if I thought about the target audience, but I think that would degrade the art, right? 

Sar: Yeah, no, what you do is great. You want it to be off the cuff and not overthink it. You have an entire company to be strategizing over, so not strategizing shitposting is the way to go. 

Jacob: Yeah, exactly. It's funny I've been doing this well before I had the company; the company has just become a part of it.

Sar: You run the company to pay the bills, but the core mission's been shitposting. 

Jacob: This is the real art, right? Finally, somebody who appreciates it.

Sar: So my very dumb reductive read of what you guys do is that you are a machine that pulls in customer and revenue data, cleans it up, makes sense of it, and spit out pretty dashboards for helping your customers get smarter about their subscription businesses. 

There are other companies building dashboards for other purposes for your customers, so you are not too obsessed with your dashboard and want other companies to incorporate your data and analytics into their dashboards so that your customers get a more holistic view of things. You are a plumbing network and a data enrichment layer where there will always be fewer pipes flowing into you than flowing out because there are only so many app stores and platforms on which your customers can build subscription businesses. You also take it a step further by enabling your customers to communicate with their users. Am I looking at this correctly?

Jacob: Yeah. It's like taking a very bad JSON file and turning it into a slightly more useful JSON. Another key aspect of what we do is answer the important question of "does this user have a subscription?" in real-time. It seems like a trivial question, but building all the tech to do this is a drag. We get you going in a few hours and get us in your app's infrastructure. We're the ones processing your receipts and unlocking content for you. The infrastructure aspect is our acquisition model. We get subscriptions up and running in your app. And then our retention model is all that you were describing. Here are your dashboards; take the data wherever you want. Going forward, we build even more of that ecosystem ourselves over time. 

Sar: So the wedge is an engineering use case of making it easy to use your SDK to get subscriptions up and running. And then, the product managers can use you to understand the subscription metrics and improve the product. The marketers can use you to reach out to users at the right points throughout the lifecycle, from acquisition to cancellations. 

Jacob: Yes, correct. 

Sar: This brings me to the topic of you liking Apple's IAP, the in-built payments and billing system for all iOS subscription apps. I wouldn't have expected that, given the narrative around Apple bullying the devs into using their payment system to manage billings and customer support. Commentators and nerds rail against IAP all day online. I'm surprised you don't hate IAP.

Jacob: In some ways, it's an intentional contrarian take because taking contrarian positions is fun. I don't think IAP is a bad deal. Many people see the 30% take rate but don't realize that all the user friction, management, and tax implications add up without IAP. It's probably not the best, but it's not too bad. 

The problem I'll push on is Apple's overarching control and the capriciousness they treat their partners. It is funny because we could potentially stand to benefit a lot if they dropped the IAP. We could become a big purchasing system for apps going off the App Store. We've built stuff to be prepared for that, but I keep cautioning my team that it will not change the world regarding mobile monetization. IAP will continue to be the preferred monetization for most consumer apps; there will be some big apps that can work around it. 

Sar: Does that make your life harder? You still have to get the data from Apple. Besides the take rate, the biggest complaint about IAP has been how Apple does not share customer data easily and how developers can't reach out to users at critical points around cancellations, trials, refunds, etc. As a consumer, I love IAP. And I also see your point about it being the preferred option for most apps even if Apple were to open it up. But how are you thinking about what you guys do in a world where IAP continues to be dominant? 

Jacob: It did create a niche for us. A lot of the features of our product are because of those shortcomings. Being able to talk to your users based on subscription status and what you talked about is so hard. You can do that, but you have to build difficult infrastructure. Apple doesn't let you do that out of the box. And that's what we do. Let's say you're a website using Stripe. You can quickly get a list of all active subscribers and dump it in Intercom. That's trivial. You just can't do that on an iOS or Android system. They don't provide that functionality. They don't think that way. They never built the systems like you would build a modern platform. So we fill that gap. There's a reason I started a B2B company instead of a B2C company. I was tired of all that crap.

The simple things Apple doesn't let developers do still blows my mind. They don't allow developers to manage their refunds. I, as a developer, cannot tell Apple to refund a customer on my behalf. It's a terrible experience for everyone. My mom went through this and asked, "have you heard about in-app purchases? I made an in-app purchase, and I didn't want it. The developer told me to talk to Apple. I can't believe it." I can't believe it either, mom.

Sar: Ha, that's funny. It's like the mobile version of buying United tickets off of Expedia, and then you are stuck in this telephone game between those two.

Jacob: Yes, exactly

Sar: How do you do what you do under those constraints? 

Jacob: We do the best we can on top of the constraints. For instance, a big part of what we do is the individual identifiability of a user. Apple gives you this receipt file. And if you query that with them, they will tell you the status of it, but they won't allow you to ask them who are all my subscribers, for example. They will anonymize all of that. So what we do technically is if you, the developer, would give us a little receipt token, we'll create a record in a CRM for you, and we will keep those things tied together. And so whenever you need to reference a customer, you come to us, and we'll tell you, like, here's the receipt file on Apple or Google. Here's how you can refund them. If they need to manage their subscriptions, here's a link that'll take them to the right platform. 

Sar: Isn't it insane that all it takes for Stripes of the world to have the edge over the App Store is to give you a list of all your customers along with their emails?

Jacob: Right? It's the market dynamics. Stripe had to prove to the world that they would be better than using authorized.net and whatever else people had used. They had to build a great developer experience, which was nice. Apple didn't have to do anything. They just said, here's what you get, sorry. There's nothing you can do. And that's why many developers have run to the press or regulators. If they had to react to the market pressure, they would be moving faster than they are. 

Sar: Apple being a pain in the ass for developers has created both the opportunity and challenges for you guys. So scenario planning-wise, your product roadmap becomes a function of what changes Apple voluntarily makes and what they get forced to do with regulations.

Jacob: Yeah. We're at the point now that it will get more complex regardless of where the regulatory outcomes end up globally. I don't know who will be the winners and the losers. Still, complexity will probably increase because there will be more payment options, more possibilities, and more things developers will want. Apple will add complexity or be forced to, which feels bad, but that's a win for us. We can help with complexity. It's what we do. We encapsulate complexity. 

Let's say Apple lets you add another payment provider in your app. I'm not keen on building something that's not that lucrative. If adding a Stripe paywall inside your app is something you're allowed to do, we'll make it possible. But it's not something I'm going to push in a campaign like RevenueCat's to replace IAP with credit cards if I don't think that's the best user experience and developer experience. If that's going to lose developers' money, I don't want to build features that push people down that path.

Sar: How would developers lose money with Stripe paywall? 

Jacob: Well, you're going from a 30% cut or sometimes a 15% that Apple charges to 3-5% you get charged on credit cards. But the customer will have to go through many more steps, right? They'll have to create an account if they haven't already, and they'll have to add their credit card. Every time you make people click another thing, your retention in that funnel goes down.

Sar: Right, I agree. I think people underestimate the top-line loss due to the fall in conversion in this debate. Why would you want to take a position on whether IAP alternatives are better for developers? Wouldn't you want to be agnostic to what developers use and just help manage subscriptions and create universal customer profiles? What difference does it make to you if your customer uses an IAP alternative in the app?

Jacob: Maybe I take a different view than a pure infrastructure company would, which is that, depending on the tooling, what we emphasize and suggest will lead developers down one path or another. And if we know that one path is not suitable for a developer, we just know in most cases it's not going to be a worthwhile exercise, I'm not going to make it highly promoted. We'll support the functionality, but I don't want to pivot the company to be like, oh, we're going to help you avoid Apple's taxes unless that's good for developers. If that's good for developers, that matches our mission, and that's what we'll do.

If we don't have the data that shows that it's going to help developers make more money, we're not going to emphasize it. We'll make it possible; we try to let developers do as much as they want, but we also have to focus. If we don't have evidence to show it is better for developers and consumers, it won't get highly prioritized if that makes sense. 

Sar: Besides Apple, you work with Android and other platforms. Is Apple the most complex to work with? 

Jacob: No. In terms of edge cases and complexity, Google is technically just as bad. And then we've recently added Amazon too, which is very nascent and not ready for prime time. Subscription billing is a hard problem. It's stateful. It moves in time. The state machines are giant. It's very stateful. It moves in time. It's a tricky problem. Stripe, which we also support, is as good as I think anybody can do it. 

Sar: How do you see Stripe? Right now, they are not in Android or Apple subscription apps. What's your relationship with them? 

Jacob: Everybody's been predicting our Stripe acquisition since the beginning. And nobody's called me yet. So I don't think it's imminent. 

Sar: Maybe they are reading this right now. Eighteen months from now, when you write the M&A blog, you'll mention this is where it started. 

Jacob: Yeah, full attribution to this chat. No, we're not for sale, but that's, you know, the perfect time to start having conversations. In all seriousness, everything Stripe does is to drive transactions through its core credit card processing system. What we do is not like that. What we do is a data enrichment play. We don't handle money movement. One of the tricky things about RevenueCat as a business is that our market is strictly smaller than theirs. As long as we play with the app stores, we are a smaller segment. Stripe can serve every business in the world. So I see it as a really good partner and role model. It's the same with all payment providers. It's a tough problem, and we've spent a lot of time on it and don't even have it fully right yet. So the ability to tack this on as a side feature seems unlikely to do well. 

Sar: No matter how good the app stores and payment processors get at subscription billing, they are limited to what revenue they see in their platform, right? You are a neutral player and transactions agnostic. You don't care where the revenue is coming from. 

Jacob: That's right. And that was in the company's design when we set our mission very early. We wanted to be fully aligned with the monetization journey of developers. And that's why we charge developers a take rate, even though we're not processing money for them. And it's sometimes a hard pill to swallow for developers.

Sar: I was curious about your biz model being a mix of subscriptions and a take rate. Have you considered using RevenueCat for RevenueCat?

Jacob: We recently added metered billing support in our Stripe integration. And so have now the ability to throw our revenue into it. I haven't done that because I have to subtract it back when I report to investors. I don't want to throw our data in there.

It's going to cause me a headache in the analysis pipeline. So I haven't done it, but it would be good to like dog food. Technically we could track RevenueCat's subscription business in RevenueCat, but we're serving low ACV consumer subscription companies on the App Stores. And that's the use case we want to focus on. I'd be afraid we'd over-emphasize our problems, which aren't our customer's problems.

Sar: Yeah, that makes sense. Talk more about the business model. Why not just stick to subscriptions based on features? You have tiers based on volumes.

Jacob: I modeled out a whole lot of different possibilities in the early days.

But none of them were as clean as just saying, hey, give us some percentage of your revenue. If you're small, you pay little; if you're big, you pay a lot. It's very equitable in terms of customers. It's also scalable for us. We have 10,000 apps on the platform, but there are probably only a few hundred that generate most of our revenue. So it's progressive taxation. I like that. Over time, we have to keep building value for those big customers to keep justifying RevenueCat to them because the initial pain is where it's most acute. And then it's like, I'm paying a lot for charts. And it's like, well, you're paying a lot more than that. But we have to keep making that case over and over. 

Sar: Yeah, it's the classic graduation problem.

Jacob: Yeah. Luckily we're not as concentrated. I always remember the classic Twilio and Uber story.

Sar: Or Marqeta and Cash app.

Jacob: The nature and distribution of the businesses we serve don't concentrate that heavily. We have to keep earning it every year and like doing more to justify our place on the P&L of our biggest customers. 

Sar: So, switching gears a bit. I was looking at the career page, and you had a line that said all leadership meetings are recorded, and all board decks are accessible to anyone at the company. Has that resulted in awkward conversations?

Jacob: I'll lightly edit board decks sometimes, but I send them out to everyone. I also send out investor updates the same day. It would certainly be easier if I started playing secret games and stopped sharing. I could control the narrative better. I could have "the reality" and "the real reality." But I think that wouldn't help the company. I don't think it would make us operate better. Sometimes it bites me because I share scary things. This summer, with the market turn, we've seen softness in our growth numbers like we haven't seen in a while.

I've sent some pretty sour investor updates over the last three months. Initially, a few people were like, oh, are we going to die? And I was like, probably not, but like, maybe. I know you're a little scared, but welcome to my world. If I present the problems on my mind, people will often bring me things I wouldn't have thought of because they're seeing stuff on the frontlines. I have lost the frontline visibility I used to have when I talked to customers and worked on the product daily. And so, I try to propagate my thinking as much as possible so folks can make decisions or take in information and funnel it back to me.

Sar: Ah, so you believe that by sharing the investor updates and board decks with everyone, you are making everyone aware of what's top of mind for you so that they can passively stay in the know.  

Jacob: Yeah, that's how I write them. I'm trying to be coherent with my plans and my thinking. I do weekly Friday updates, monthly investor updates, and quarterly board-level memos. 

Sar: You guys are fully distributed?

Jacob: Yeah, I come down on being pro remote just because it's the bed I made, I have to lie in it, but I don't think I would change it. If anybody tells you it's magically the perfect way to work, they are a liar. But the flip side is I don't have to worry about where somebody is whenever I want to hire them.

Sar: You now have YC and Index on your board. What's most helpful about board meetings? 

Jacob: The most helpful aspect of it is just forcing accountability on me every quarter to ask where I was last quarter. So I always read the previous board memo and see where we were before I start writing the current board memo. What did I say I was worried about last quarter, and what progress did I make in that time? Technically I could walk out of that meeting without my job. As a founder, it's easy to drift off into the clouds. I don't think YC or Index will fire me in a meeting, but knowing it could happen in the back of my head makes me a little more like, okay, I need to get my shit together.

Sar: What’s the most expensive mistake you have made so far?

Jacob: We wasted 5-6 figures in AWS all the time because we missed a checkbox. That’s just normal computer stuff. Probably the most expensive mistakes tie to opportunity cost and not exactly dollars. For example, we tried to go all in on an enterprise sales motion before we had the product and the company oriented for those deals. On a raw dollar basis, it wasn’t a total waste; we closed some good ones. But when we couldn’t get the flywheel going, we had spent a year not focusing on growth fundamentals and are paying for it now. A deferred year of compounding is very expensive. 

Sar: What have you changed your mind on recently?

Jacob: I used to believe companies don’t get better with scale. I’ve got this total chip on my shoulder that big companies suck and that every company eventually becomes this lumbering bureaucratic nightmare. I think that happens to many companies, but great companies scale without falling into that. RevenueCat goes in waves, where we add layers of process that feel burdensome, then we trim and adjust and get faster without a huge loss in marginal productivity. I hadn’t realized that talent density could increase as a company grows over time. Your brand gets bigger, better people find you, and they value a slightly different environment than the crazy first 10 or 20 people. It’s been fascinating to watch.

Some of my previous chats :