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 100 remote team members spread across 21 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
Historically, Engineering at RevenueCat started with a handful of product engineers reporting directly to me. There were no teams or managerial structures in place. As of June 2026, RevenueCat Engineering has grown to include:
- Over 100 fully remote team members spread across:
- 21 countries
- 11 different time zones
- 19 cross-functional teams, including customer-facing, product, data, and infrastructure
- Two technical support teams:
- Development Support Engineering, serving self-serve customers
- Technical Account Management, serving implementations and enterprise customers
- OCTO (Office of the CTO), a small group of senior ICs reporting to the CTO, focused on bootstrapping new bets, unblocking critical projects, and carrying RevenueCat’s technical and cultural standards into ambiguous work.
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 100K 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 $14B+ annually.
- We handle 3B+ 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
- “Almost done” is worse than “not started”: Company value #2 is “always be shipping”. Engineering sets the standard for what shipping velocity means for the entire company. 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.
- Small teams move faster: Large teams create coordination overhead, consensus loops, and unclear ownership. Small teams with a clear Engineering DRI (technical lead) can move faster, make decisions closer to the work, and show progress every week. This matters even more now that AI can increase the leverage of small groups. We should prefer small autonomous teams by default, as long as managers and product leaders keep the product cohesive.
- Fires over features: Building new features is the most exciting part of our work. However, 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.
- 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.
- 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.
- Use AI, but own the output: Everyone should actively use AI tools and learn how to get leverage from them. People who do not adapt will fall behind. But AI does not change ownership. Even if an agent writes the code, you own what gets shipped.It is fine to open PRs you could not have written without AI, as long as you fully understand the output. Read the code, ask AI to explain it or review it if needed, and only then ask a teammate to look at it. Otherwise, we risk overwhelming the maintainers, especially in large shared codebases like frontend.
- 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
- 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. Create an incident and centralize all communications in the designated Slack channel. It’s always better to trigger a false alarm than to ignore a potentially significant issue. Time is critical.
- 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.
- 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
- 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. Plus, it’s a lot more fun! To build a winning team, we must hire, promote, and manage performance exceptionally well. We cannot afford to make exceptions – every seat counts.
- Use OCTO for ambiguous, high-leverage work: Some work does not fit cleanly inside existing teams. New bets, critical technical problems, and ambiguous early-stage initiatives often need startup-level speed without diluting the culture or overloading current teams. OCTO exists for this: a small group of trusted senior ICs who can bootstrap new bets, unblock important projects, and provide a strong signal on technical and cultural health. OCTO is not a replacement for teams. It is a way to start or rescue important work until the right long-term ownership exists.
- 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.
- 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 policies, we will maintain most of our historical processes while also implementing continuous and one-off actions:
- We will prefer smaller autonomous teams with clear Engineering DRIs, especially for product surface areas where ownership, speed, or decision-making are unclear.
- EMs will oversee multiple small teams when appropriate, while keeping performance management separate from the Engineering DRI role.
- We will use OCTO to bootstrap new bets, unblock critical projects, and carry technical and cultural standards into ambiguous work until a durable owner or team exists.
- We will continuously monitor and support the creation of new teams or sub-teams, ideally at least twice a year.
- We will continue using Rootly for incident management and ensure the practice of writing blameless post-mortems.
- 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. We must learn to optimize this process and become more efficient over time.
- To guarantee consistency and fairness, we will adhere to our standard hiring interview loop. While loops may evolve to address deficiencies or new areas of focus, every candidate should go through the same interview process.
- 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.
- Over the past few years, we’ve made remarkable progress in minimizing end-user disruption during outages. However, our developers sometimes detect issues with our systems that affect their trust. We will develop 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.