Inside RevenueCat’s engineering strategy: Scaling beyond 32,000+ apps

When RevenueCat started back in 2017, we were just two developers with a big idea: to make in-app subscriptions easier for everyone. Like most startup journeys, ours was filled with ups and downs. We made some good decisions and more mistakes than we’d like to admit, but we learned a lot — especially about building software quickly and reliably for hundreds of thousands of users.

Through these experiences, we developed a shared work ethic and values that ultimately shaped the culture of RevenueCat. As our team grew, this culture naturally evolved into a strategy that new members learned through observation. While it was never explicitly written down, this approach became an integral part of how RevenueCat operates.

Now, with over 50 remote engineers spread across 14 countries, we want to share the strategy that guides our engineering decisions, and how we’ve structured our team to build, maintain, and grow RevenueCat into what it is today.

The engineering team’s mission

Make great software that helps developers make more money. That’s our mission in RevenueCat’s engineering team. Founded by developers, for developers, our culture is deeply rooted in engineering. It is the foundation and most vital function of our company.

Internally, the success or failure of every other team, and indeed the company, is downstream of what Engineering builds. Without a great product that developers love, RevenueCat cannot succeed.

Externally, we are a critical component for tens of thousands of apps. Our work directly impacts the monetization, analytics, growth, and even app store ratings of our customers’ apps. If half of our tracked revenue goes to salaries, we could be supporting more than ten thousand jobs worldwide. Our customers have chosen to trust us with one of the most critical aspects of their apps, and we must never take that trust for granted. Building a reputation takes years, but it can be lost in an instant.

Diagnosis

RevenueCat started with just a handful of product engineers reporting directly to me. There were no teams or managerial structures in place. Fast forward to August 2024, and RevenueCat Engineering has grown into:

• Over 50 fully remote team members spread across 14 countries and 8 different time zones.
• 9 cross-functional teams, including customer-facing, product, data, and infrastructure.
• Product and design teams.
• Two technical support teams:
  • Development Support Engineering, serving self-serve customers.
  • Technical Account Management, serving implementations and enterprise customers.

The scope of our work

Our vision is to reduce the amount of custom work developers need to do to monetize their apps, allowing them to focus on what truly matters: building their unique business. We need to eat their pain, stay current with app store changes, and continuously integrate new stores. Every leaked abstraction is a failure of RevenueCat. Currently:

• We serve over 32,000 apps, ranging from small indie apps to some of the largest in the app stores.
• We maintain 10 SDKs across various stores and platforms.
• We process $4B annually.
• We handle 1.2 billion API requests per day.

Within this scope, there are three critical areas that we focus on:

We are critical infrastructure (Build)

Developers rely on us for both subscription infrastructure and data accuracy. If we experience just one minute of downtime, nearly a million API requests will fail, creating significant noise. If we ship a buggy SDK, it could potentially crash tens of thousands of apps, directly harming customer satisfaction and app store ratings.

We provide key business analytics (Analyze)

If our data is inaccurate, customers could misuse this information — overspending on ads, sending incorrect reports to investors, and facing the embarrassment of later corrections.

We offer powerful growth tools (Grow)

Our tools — such as experiments, paywalls, and targeting — enable developers to maximize their revenue. This is a win-win: as they make more money, we do too, since our business model is tied to their revenue.

Guiding principles: The backbone of our strategy

Our engineering strategy is guided by a set of principles that fall into three key categories: Building, Incidents, and Growth. These principles shape every decision we make and help us tackle the challenges we face as we scale.

On building

1. “Almost done” is worse than “not started”: Company value #2 is “always be shipping”. We must relentlessly reduce scope and consistently deliver the minimum viable product. Then, analyze, optimize, and iterate. Every week, every day. This is the only way to validate that what we’re building is truly what our users want.
2. Fires over features: Building new features is exciting, but when something breaks or affects customers (e.g., outages, crashes, data inaccuracies, regressions), it must take priority over unshipped work. Context switching is tough, but this approach ensures that RevenueCat continuously improves over time.
3. No change is innocuous: Never assume that a small deployment won’t impact the entire system or that a minor metric calculation change will go unnoticed. These seemingly small changes can be the most harmful because they often receive quicker, less thorough reviews. Avoid cowboy deployments and embrace extreme caution. Plan, monitor, and remember that testing is not optional.
4. Do the dirty work: The problems we solve aren’t glamorous. The app stores are constantly changing and riddled with bugs and inconsistencies. Our job is to fully abstract these issues and deliver an exceptional developer experience out of the chaos. Every “if app == app_store this else that” our users have to write is a failure of our abstraction.
5. Be pragmatic: RevenueCat is not the place for experimenting with the latest trendy technology. We prioritize proven, stable technologies that we know well. We don’t do full rewrites. Only introduce new technology when our current stack has issues. If that’s the case, build a strong case, outline a migration path, and ensure team members and leadership have the opportunity to review.

On incidents

1. Escalate early: We should aim to detect problems before our customers do. However, if a customer or teammate notices something unusual, investigate immediately and escalate according to our incident response guidelines. It’s always better to trigger a false alarm than to ignore a potentially significant issue. Time is critical.
2. Do not hide the nasty stuff: No matter how uncomfortable it may be, sweeping issues under the rug is harmful. People will notice. Transparency builds trust. If something is customer-facing, open a public incident on the status page as soon as possible, and keep it updated regularly.
3. Analyze and automate: Mistakes happen, and there’s no blame in making them. However, there is blame in not taking responsibility and learning from them (company value #3: “own it”). Once the root cause is identified, it’s not enough just to document it. Implement automations so that other team members don’t have to think about it and won’t make the same mistake again.

On growth

1. Build a winning team: We chose a global remote model with the same pay everywhere. This principle has served us well, but it only works if we bring extraordinary people to the team. To build a winning team, we must hire, promote, and manage performance exceptionally well. We cannot afford to make exceptions—every seat counts.
2. Learn and educate about the space: Ideally, everyone would be a domain expert before they start, but that’s neither realistic nor expected for new hires. However, everyone is expected to continuously deepen their understanding of our space and our customers’ challenges. Engage with customers, listen to the Sub Club podcast, attend conferences, reply to support tickets, and use the product. If you feel you’re not learning enough, make sure to talk to your manager.
3. Support and infrastructure cost should scale sublinearly: As we grow, we must optimize our processes, as well as human and computer costs, in line with economies of scale. We should treat every support ticket category as a sign of a product or documentation failure and work to improve accordingly.

Coherent actions: Turning strategy into reality

To achieve our guiding principles, we will maintain most of our historical processes while also implementing continuous and one-off actions:

• Allocate reactive teams: We will allocate at least one team that is reactive, primarily focused on enterprise customer requests. Each team will determine how they will rotate responsibilities for handling day-to-day tasks that are outside the roadmap but do not qualify as incidents.
• Host regular Engineering All-Hands: We will host two synchronous (and recorded) Engineering All-Hands meetings each year, one of which will be held in person.
• Create and monitor new teams: We will continuously monitor and support the creation of new teams or sub-teams, ideally at least twice a year. For example, in our 2024 offsite, we identified the need to establish two new core teams (Frontend and Data) and a dedicated Monetization team.
• Continue using Rootly for incident management: We will ensure the practice of writing blameless post-mortems and make use of Rootly for incident management.
• Add new stores or payment providers: To reduce complexity for our customers, we will add new stores or payment providers to RevenueCat. Although the number of potential additions is finite, we anticipate integrating a few each year and aim to optimize this process over time.
• Adhere to consistent hiring practices: We will guarantee consistency and fairness by adhering to our standard hiring interview loop. While loops may evolve to address deficiencies or new areas of focus, every candidate will go through the same interview process.
• Prioritize relevant experience for customer-facing roles: For customer-facing roles, we will place a high value on experience in mobile apps, in-app subscriptions, or familiarity with RevenueCat, as this significantly speeds up onboarding and ramp-up time.
• Develop a new definition of uptime: We will create a new definition of uptime that accounts for aspects that may go unnoticed by app users but are critical to RevenueCat customers, allowing us to track and set a lofty long-term goal for exceptional reliability.

What’s next for RevenueCat Engineering?

As we continue to grow, our focus remains on building reliable, scalable, and developer-loved tools. We’ll keep refining our processes, learning from our customers, and pushing the boundaries of what RevenueCat can do. If you’re a developer interested in helping us tackle these challenges, we’re always looking for talented people to join our team.

Interested in joining us on this journey? Check out our current openings and see how you too could help developers make more money.