YC Root AccessRevenueCat: Powering Subscriptions for the App Economy
CHAPTERS
RevenueCat’s core mission: make in-app purchases painless and boost app revenue
Jacob explains RevenueCat as subscription/in-app purchase infrastructure that helps developers monetize without getting bogged down in payments plumbing. The product promise is straightforward: easier implementation, fewer headaches, and better outcomes for app businesses.
- •RevenueCat simplifies in-app purchases and subscriptions for mobile apps
- •Goal is to help developers make more money by reducing monetization friction
- •Focus on making monetization “not so painful” for small teams
- •Acts as infrastructure so teams can focus on core app value
Why in-app subscriptions were such a mess: rebuilding payments over and over
Jacob and Miguel describe firsthand pain from building subscription systems at a previous mobile app company. A huge share of engineering time went into monetization work that wasn’t differentiating, including dealing with multiple app stores and changing requirements.
- •They implemented subscriptions early (circa 2011) and found it extremely painful
- •Multiple app stores and evolving store behavior forced repeated rebuilds
- •Monetization consumed ~half of engineering effort on a small team
- •Payments work distracted from building the actual product value proposition
The cross-platform gap Apple/Google didn’t solve (and why that left developers stuck)
They argue Apple and Google lacked incentives to make a unified, cross-platform solution that gave developers a single view of their subscription business. RevenueCat positions itself as the neutral layer that standardizes and unifies data and workflows across platforms.
- •Apple and Google are not incentivized to interoperate with each other
- •Developers need a unified view across stores to “see the full picture”
- •Store systems are powerful but not optimized for developer experience/fit-and-finish
- •Developer time spent here benefits nobody (users don’t care about the plumbing)
From internal solution to startup: generalizing the “RevenueCat way”
They had solved the problem for one app, but the company was born from the insight that the same solution should be generalized for tens of thousands of apps. Their lived experience created credibility in early customer conversations and helped them set a de facto standard for how developers think about subscriptions.
- •Key challenge: generalize from one app’s solution to thousands of apps
- •They brought strong opinions on how subscriptions/data “should be done”
- •Early founder-customer trust came from shared pain (“I know what you’re going through”)
- •Aim to create a standard approach to subscription analytics and management
Choosing to start: timing, founder motivation, and committing to the leap
Jacob and Miguel discuss why they left jobs to start the company: personal founder ambition, love of “zero to one,” mutual respect, and a timing window. Jacob set a personal deadline (around turning 30) to finally start a company after years of discussing the idea.
- •Jacob wanted to found a company; Miguel loved zero-to-one building
- •They’d discussed making it a business years earlier but timing wasn’t right
- •Mutual respect and enjoyment working together drove the decision
- •Jacob set a personal deadline to start, which catalyzed action
YC and early go-to-market: “do whatever it takes” to get the first customers
Jacob details scrappy early customer acquisition: reaching out as an iOS developer, offering to fix code issues in exchange for SDK adoption and a revenue share. During YC, warm intros and YC brand credibility accelerated adoption and created compounding social proof.
- •Cold outreach offering hands-on help: fix problems + add SDK as the trade
- •Early deal framing included “1% of revenue in perpetuity” style agreements
- •First customers were sometimes “random people from the internet” due to shipping delays
- •YC network + Gustaf intros led to meaningful early switches and social proof loops
Finding product-market fit: organic pull, breaking servers, and overwhelming demand
They describe PMF as the moment growth happens without heroic founder selling—and when infrastructure starts failing under load. Customer demand outpaced their bandwidth, and a PMF survey returned extremely high scores, reinforcing the signal that they’d hit a strong fit.
- •PMF felt like customers arriving faster without additional effort
- •Operational signal: servers/bandwidth breaking under growing load
- •Customers actively requested more than the team could build
- •PMF survey indicated very high satisfaction (e.g., ~92%)
Selling to developers without “sales”: technical pull, long-tail leverage, and word of mouth
Their advice: don’t do traditional enterprise-style sales motions for developer tools. Instead, make adoption easy, answer technical questions well, and let developers pull the product in—while treating indie/long-tail developers as a powerful distribution engine.
- •Developers dislike sales; win by being useful and technical-first
- •Optimize for discoverability, easy integration, and quick time-to-value
- •Start bottom-up rather than top-down executive pushing
- •Indie/long-tail devs become champions and later carry tools into bigger companies
Scaling the organization: staying close to customers at 100+ people
As the team grows past 100, they emphasize intentional customer proximity: founders staying reachable, building customer-heavy information feeds, attending developer conferences, and encouraging everyone internally to talk to customers without bureaucracy.
- •Jacob uses X/Twitter as a real-time customer listening channel (follows customers back)
- •Conferences provide candid, high-signal feedback on frustrations and wins
- •Founders say “yes” to customer meetings as “good medicine”
- •Cultural norm: anyone can email/call customers—no special permission required
Operating discipline and transparency: consistent metrics and investor updates
Jacob explains the habit of sending consistent investor updates and keeping metrics stable over years. They treat it as a discipline mechanism that forces honesty, aligns a distributed team, and creates a shared “ground truth” for decision-making.
- •Investor updates are sent with strong regularity; metrics rarely change
- •Transparency extends internally (team sees ~99% of the data)
- •Discipline is partly self-management: forcing reality checks each month
- •Written updates create alignment for a fully distributed, multi-time-zone team
Building a remote-first company (pre-COVID): hiring advantages and operating systems
RevenueCat became remote-first largely out of necessity due to Bay Area hiring competition, then formalized the approach by borrowing from GitLab-style practices. They highlight benefits in talent access and coverage, plus the need for strong systems, documentation, and a clear compensation philosophy.
- •Remote started “accidentally,” then became strategy; COVID switch was easy
- •Remote expanded hiring pool globally and reduced visa/immigration constraints
- •Requires systematized communication: writing, artifacts, Looms/videos, Slack norms
- •Clear, consistent compensation philosophy is crucial for remote scaling
- •Distributed team helps operational coverage for critical infrastructure
Competition and platform risk: thriving alongside Apple/Google/Stripe
They acknowledge platform dependency and the risk of incumbents, but argue scale and relationships create some protection. The broader takeaway: most modern businesses rely on major platforms, so founders should focus on building indispensable value rather than worrying about every ‘what if.’
- •They worry “to some degree” about being run over by incumbents
- •Scale brings partial protection: they represent a meaningful chunk of store ecosystem
- •Maintaining formal/informal relationships with platforms matters
- •In 2025, greenfield independence is rare; focus on building massive value
Co-founder dynamics over time: trust, mutual respect, and investing in the relationship
Jacob and Miguel describe the co-founder relationship as unlike friendship, marriage, or coworking—yet containing elements of all. Their guidance centers on mutual respect, assuming good intent during disagreements, and making time to strengthen the relationship, especially in remote settings.
- •Co-founder relationship is unique and evolves as the org scales
- •Mutual respect and philosophical alignment reduce destructive conflict
- •Disagreements are manageable when you trust the other isn’t “trying to screw you”
- •They keep communication organic but prioritize picking up and making time together
Market shifts and the Epic vs. Apple fallout: alternative payments and real-world impact
They cover how the Epic legal battles led to a U.S. ruling limiting Apple’s ability to block alternative payments links. RevenueCat observed the impact as modestly positive but smaller than many predicted, suggesting app store economics are closer to “market optimal” than expected.
- •Epic pursued antitrust via deliberate App Store rule-breaking to provoke litigation
- •Judge ruling: Apple can’t prevent alternative payments links in the U.S.
- •Measured effect: slightly positive but relatively minimal vs. predictions
- •In-app purchases became unexpectedly central in major legal/policy battles
Founder advice and long-game mindset: ignore noisy advice, don’t quit, build the company you want
Their closing advice blends pragmatism and resilience: expect hardship, talk to customers constantly, and trust yourself over external advice. Jacob emphasizes building a culture you enjoy, focusing on month-to-month progress, and treating perseverance as a decisive competitive advantage.
- •“Do YC,” but also be careful about blindly following others’ advice
- •Expect “glass eating”: hard work, odd hours, and unequal intensity vs. employees
- •Optimize for velocity and consistent monthly progress rather than distant forecasts
- •Mission/culture matter—founders can and should fix a company they dislike working at
- •Perseverance is central; co-founders help prevent quitting when things get rough
