Product-Market Fit and Pragmatic AI: Insight from RevenueCat's CTO Miguel Carranza
In this episode of "How Many CTOs Does It Take?" podcast, hosts Scott Porad and Brad Hefta-Gaub" interview Miguel Carranza Spanish-born co-founder/CTO of RevenueCat, who describes discovering subscription billing pain while building the Elevate app and turning that hard, "boring" problem into a YC-backed business. He explains RevenueCat's scale (billions of API requests/day) and the resulting priorities: product-market fit, reliability/security, and sustaining culture in a fully remote team across 27 countries. Scott and Brad commiserate with Miguel about avoiding platitudes in company values by grounding them in specific principles—always be shipping, customer obsession, ownership, balance, pragmatism, and healthy paranoia—reinforced through public shout-outs and performance expectations, plus examples of choosing customer support over strict entitlement. The discussion covers AI's tailwinds, internal adoption, standardizing workflows, a rule that PR authors must understand every line, and why auto-generating PRs from bug reports still requires context and triage.
- How Many CTOs Pod: https://howmanyctospod.com
- Scott Porad: https://www.linkedin.com/in/scottporad/
- Brad Hefta-Gaub: https://www.linkedin.com/in/bradheftagaub/
- Miguel Carranza: https://www.linkedin.com/in/miguelcarranza/
- RevenueCat: https://www.revenuecat.com/
#TechPodcast #EngineeringPodcast #DevTalks #PodcastForDevs #HowManyCTOs #Podcast #CTOs #CTOPodcast #ChiefTechnologyOfficer #Technology #Engineering #SoftwareDevelopment #SoftwareEngineering #TechLeadership #EngineeringLeadership #EngineeringCulture #TechDebates #SoftwareDevelopment #StartupSuccess #StartupCulture #TechEntrepreneurship #Innovation #AI #AIRevolution #AIAssistedProgramming #AICoding #RevenueCat
Guest
Miguel: This is what makes a company unique and you need to understand that if you're trying to make a company in which like everybody fits and everybody is happy then nobody's happy.
Brad: All right. Welcome, everybody,
to another episode of the How Many CTOs Does It Take podcast.
My name is Brad Hefta-Gaub, and my trusty co-host is...
Scott: Scott Coran.
How are you doing today,
Brad?
Brad: It's all right. I'm doing great,
Scott.
It's good to see you.
And today we have a really interesting guest,
Miguel Carranza. Did I say your name correctly,
Miguel?
Miguel: That's perfect.
Brad: Awesome.
And welcome to the podcast,
Miguel.
You were just telling us how.
how you feel like there's a dearth of podcasts for CTOs. And so here you are on a podcast for CTOs by CTOs talking about CTO stuff.
Miguel: Tell Yeah.
Brad: us about yourself.
Tell us how you got here.
And yeah,
let's get into it.
Miguel: Thank you very much for having me. This is super exciting.
My name is Miguel.
I'm originally from Spain,
from the south of Spain,
and I got my first computer when I was eight.
And I guess that's when I fell in love.
of with a wall of computers and I wanted to come to Silicon Valley because that's where all the magic happened or that's what I thought I mean I'm dating myself I guess but that was a Pentium 1 one of the first Pentiums it didn't even have Windows 95 back in the day uh but yeah I fell in love with that and I kept learning as much as I could started computer science at university that is when I realized that coming to the U.S. wasn't as simple uh you needed a visa there were like many
many other things.
But eventually I got the opportunity to join a small startup in San Francisco,
originally as an intern.
And we were essentially,
we were a mobile app that was Duolingo before Duolingo existed,
kind of. It was language learning.
It got a big round from Sequoia, the company started growing and got a full time offer at that point but yeah the only thing that came up and we needed to build a new product and that's where that's when I met my co-founder he joined this company like four or five weeks after I did so we had been working together for a long time before starting revenue cut.
And essentially with this new product that we were building was another mobile app. One thing that we realized was that the one-time purchase business model wasn't going to work.
Because we were generating very expensive content and new mini-games every month,
so we were like, okay, we need to do subscriptions.
Because that's going to... recurring revenue,
SaaS,
that's what's going to solve all the problems,
right?
Brad: Yeah, totally.
Miguel: Back in the day, it was more difficult because you needed explicit permission from both Google and Apple because they wanted to take their 30% cut too and they didn't want the app stores to look scammy. But also...
The APIs were not that great.
We thought it was going to be very easy,
and again, it wasn't rocket science,
but it wasn't super easy to implement.
And as the product ended up being pretty successful,
it was up half of the year in 2014. It was called Elevate. It was a brain training app.
But yeah,
as it was scaling, we started to see all the problems,
all the edge cases,
race conditions that the App Store had.
The APIs were inconsistent and again when you're making
A thousand dollars,
two thousand dollars a month, you won't see them. But when you're making millions of dollars,
then you start seeing all the problems and people complaining,
customer support tickets,
people say like, hey, I paid for this, this is a scam and it's not good.
We became experts in this particular problem.
It was only just the billing, it was at the same time the growth team realized like,
oh, this is working,
we want to see the data in real time, we want to do price experiments,
we want to do...
to paywalls experiments.
We want to do targeted discounts.
We want to know in real time why somebody cancels a subscription. Can we send them another offer or something like that?
So we started building like all the data layer,
all the pipelines and all the experimentation things on top of that to the point in which it became the most challenging engineering problem at the company that nobody wanted to work on that.
We decided,
I mean, we even looked to see if somebody was doing it as a service.
We realized that nobody else was doing it.
We talked with a lot of...
Five developers and the ones who had tried,
they all told us that it was a case, that it was a tricky problem that they definitely underestimated.
At that point, again,
frankly,
I love working with my co-founder Jacob.
We're both technical people, but we were both the most senior engineers at this previous company.
And yeah,
I wasn't thinking billion dollar company was like, okay,
this product needs to exist.
Even if it's open source or whatever,
it should be good.
It's going to be a challenging project.
Yeah,
we started working on it.
Obviously, we had a lot of experience because we had been working on this particular niche problem for like four or five years at that point.
And we built the original version very quickly and we applied to Y Combinator.
I thought there was no way we could get in because it was only two guys with not a lot of revenue and stuff,
but we got in first try.
Okay.
And then the rewind combinator is when we started realizing,
okay,
this actually could have the potential to become a business.
Nobody thought this was an actual problem.
It's very niche, but we're actually getting customers and we are growing both because we're getting new users,
but at the same time, the users are making more money.
And our
Scott: Yeah
Miguel: mission is help developers make more money and our business model is we take a percentage of what you make essentially.
So people get excited when.
when they have to pay us because that means that they're making money uh so yeah it was the double way that we had to to grow uh yeah that was in 2018
Scott: I love it.
Miguel: summer 2018 and we've been doing this for a while and now yeah that team is fully remote we are i think 27 countries or something like that 140 people two-thirds of that is engineering like 97 98
The other people is in the engineering org,
so most people report to me directly or indirectly,
which is a lot. It's the biggest team that I've ever worked at for sure.
Yeah,
Scott: Yeah.
Miguel: super technical team because our customers are developers.
So even in the marketing team,
we have developers too.
So yeah.
Brad: That's awesome.
That's a great story.
I love the fact that, you know, there's so many stories where an engineer that's working on some completely different problem, some completely different application,
they see this pain point and then they say,
oh,
that's actually an interesting pain point that I bet you I'm not the only one that has that.
And that sounds like the story of RevenueCat. So that's, I love it. I love that you basically saw a pain point,
saw a problem,
had knowledge about it, and then came up with a working solution.
Miguel: pretty much i think i mean now i know a lot more but i've always wanted to like try i always loved startups so i always wanted to like oh i should start a company at some point but i do think now knowing that i know it's like many
many stars align it was the right co-founder the right timing and the right problem I do think like the fact that I feel so much connection with the problem and our users because I felt the same pain is what has made me stay that long and push through all the bad times and all that because it's I mean it's not an easy journey for sure
Brad: No, it's definitely not.
Yeah.
Scott: I think there's a really good lesson in something you said.
To engineers who think they might want to start their own company,
which is if you're working on something that's.
tricky and difficult and nobody else is solving that problem but many other companies have that problem and probably have similar teams of engineers working on it that's a signal like it's a it's a signal that there's an opportunity there
Miguel: Absolutely.
Scott: and the hard the difficulty the hardness is the signal actually if it was easy people would be doing it
Miguel: Absolutely.
And I remember this perfectly because when we got some press when we launched and TechCrunch had the...
the article and stuff and it says something my co-founder said something along the lines that we were solving a very boring and uninteresting problem that developers had uh my friends were like you're stupid why are you saying that now it's going to be very difficult to hire people and all of that and it was partially true but at the end of the day i mean there's something very powerful it's not the it's not what what makes your company unique it's true that engineers love the
the nerdy stuff and the technical challenge but at the end of the day you don't want to be wasting time it's the same thing with tokens now right like people are saying like oh ai is gonna be able to to take away all the sass and stuff and it's like yeah i'm sure that a lot of the ones that are just like insert and update data in a database maybe but also like do you really want to be burning most of your token in some things that are not unique to your product i mean maybe eventually when when the costs
don't make any sense but at the beginning you should just
Brad: Yeah.
Miguel: build your own product right oh
Brad: All right, so how long did it take,
Scott?
Scott: yeah miguel we both looked up at the clock i think it took about seven minutes to get to ai
Miguel: jesus
Brad: seven minutes
Scott: so
Miguel: all right okay
Scott: so okay so i i don't want to go down ai for a second i want to go down a different path if we could you mentioned i think you said you had about we said two-thirds of 140 people so my rough math is you got about 90 engineers on your
on your team?
Miguel: yes but not necessarily i mean i would say that's engineering product that's engineering product because also support team that our support team is very technical and they reporting to engineering they didn't used to originally but i ended up getting and they i mean obviously they help with integrations debugging uh helping with enterprise supporting it's all of that i think i mean i don't know exact numbers but i would say probably 60 to 70
are on product and infrastructure i
Scott: Yeah.
Okay.
That's great.
That wasn't my core question to be like,
so what are the big challenges your team is facing?
Like what is a team that size?
There's something every day not going right,
I would imagine.
Brad: Yeah.
Miguel: mean there's fires every fires every day i think okay i mean i i try to think about it historically how how i have been thinking about this uh on a day-to-day i mean originally for me the biggest biggest biggest
concern was like do we have product market fit are we building something people want uh luckily for both i mean we found it very quickly because we knew that the the problem and and it turns out that people wanted to pay for this so that was great then the second challenge which i think we're always gonna have is how the hell do we scale this like we are growing really fast we're critical infrastructure uh like we're doing right now
I don't know how many, I think four,
I stopped counting at some point when it wasn't my direct responsibility,
but four to five billion API requests a day,
which means that if we have an outage for one minute,
it means that, I mean, it's obvious in Twitter, everybody complains, we get support tickets because that means that somebody is trying to purchase something and it didn't go, and they got charged, but they didn't get what they paid for, which is the worst outcome.
So yes,
scaling reliability has always been a no.
and always be obviously we've learned a lot we hire really great people but it's reliability and security are always going to be something that is top of mind for for a product like ours but then frankly after that and i think when we go to like 20 30 employees my biggest concern has been culture right as a founder too it's like making sure how do we build a very solid culture that gets
even better but we don't lose the like to me the the test is like we have really good retention with the first employees we have people that joined in 2018 and they are still with us like the four the first four or five employees they're all with us and to me I want like if they if they come to me and say like oh the company is not what it used to be or it's a lot more different or like of course it has changed there but they need to be able to grow with the company but if they feel like
like the essence is lost then I then I feel a little bit worried I mean sometimes you you can never build a company that makes everybody happy but I think especially for the early ones that help shaping the culture and and where we are today I think it's it's a very good indicative
But yeah, I mean, I think at the end of the day, the way I have approached building the company and the team has been to try to hire better people than me in every area.
I think I did pretty well on the technical side of things because I never wanted to be a manager and I never liked people, I'm a computer person.
So I knew how to detect good engineers.
So I hired really good engineers.
I think I made more mistakes on the management side of things,
but we have a pretty solid structure now.
But again,
I think that's always going to be an ongoing issue,
right? It's making sure that we keep building a great team, keep hiring the best people that we can,
doing performance management when we have to,
or even fighting people when we have to, right? But like making sure that the team is a great team is what is going to make the company essentially.
Brad: I think it's interesting,
Miguel,
like this is a worthwhile moment to pause for prospective CTOs or CTO or people that are like strong technical leaders that have a vision.
I think it's so profound that you right out of the gate covered your first concern was a business problem,
not a technical problem.
Do we have product market fit?
Your second concern was a very clearly technical problem.
How do we scale to 4 billion transactions a day and provide high quality technical results?
And then your third problem, which I think is the area that so few early.
engineering leaders focus on is how do we build and maintain a culture and
Scott: Mm-hmm.
Brad: I think it's so honestly Miguel I think that's super compelling I could see Scott smiling as you were answering this question and I was smiling too because I think that that's like that's like the meat of a big thing about what we try to talk about here as CTOs like you can't ignore
Culture,
Miguel: Yeah.
Brad: you know, it's so important.
Scott: So can I riff on that,
Brad,
Brad: Yeah,
Scott: which you said,
Brad: please.
Scott: be curious, Miguel,
what was the culture that you had or you were trying to create?
What were the attributes of the culture that you wanted?
And then were there any?
I don't know,
practices or anything that others could copy from you sort of to like to keep those things in place.
Miguel: Yeah, yeah, I mean this is a great question because I always,
I didn't know,
also because I had been working with my co-founder Jacob for a very long time. So this is, when we started, this is how we were used to working and we have very similar values and way of, I mean we disagree on many things, obviously, but at the end of the day we
We have very similar values in how.
how software should be written or how building a team or even personal relationship with everybody else and I didn't used to believe in this at the beginning we said we were starting the company and I remember our third engineer I think it was he asked us directly and it was somebody that we knew that we had worked in the past with both of us and he asked me hey how does the culture look like and I was like I don't know like you tell us it's
to work with me you work with Jacob was essentially that and whatever you bring to the table that's that's what the culture is going to be but one thing that we did very early on which my co-founder Jacob before the first person joined was like oh we should write down our values or the company values of how we should we should operate I thought that was bullshit honestly because it was like no everybody wants great employees everybody wants great people great engineers but then
You start realizing like,
okay, well, there's some unique things about how we work and how we make certain decisions that might not be obvious for certain people.
And in fact, we've seen it like there's even very great engineers that might come from another environment in which maybe they are not critical infrastructure or maybe they don't care that much about testing or they don't care about something else that turns out is important for us.
So yeah,
we ended up writing our four values,
which I kind of extended a little bit more for engineering.
For engineering,
but for us, it's always be shipping,
like shipping is the most important thing.
And so that means that you need to be very pragmatic and then customer obsession,
which is like at the end of the day, as you mentioned before,
software is cool,
but if people don't use it or people don't, if it doesn't solve a real problem, then it's useless really.
And nowadays it's even worse because code is disposable pretty much.
and then own it which is ownership right like making sure like like yeah we're gonna be shipping maybe we're gonna be shipping on fridays yeah it's good it's good that we ship on friday but but make sure that you don't just ship something and go away for a vacation or for the holidays or the weekend and you leave it leave it break broken for the next people to to take care of it right um so yeah these are kind of kind of kind of the things i think for me
two things that I try to be very pragmatic right like in the in the software industry and I mean I have been long enough in Silicon Valley to see how all the hype cycles and the trendy technologies and when I moved to San Francisco the most important thing or the thing that was trendy was MongoDB and non-relational databases right at that point everybody was like okay you
okay everything is mongo everything everything needs to be non non-relational and blah blah and it's like yeah this is cool but there's there's no silver bullets right there's this solves a very particular problem pretty well but maybe for other things you can also trust relational databases or maybe you can have a combination of both systems right like you need to be very pragmatic about it and i think that's something that has worked out really well at this company even with the with the adoption of ai right like people were skeptical at first but they were very curious and then
then we've been able to adopt it in a way that makes sense for everybody.
And yeah,
I would say that.
And the other one is like making sure that like being extremely paranoid. I think when you're joining a startup, you need to be very optimistic because I mean, chances are that you're going to fail, but you need to be optimistic and believe that you're going to achieve something. But at the same time, if you're building critical infrastructure, there's value in being extremely...
Pessimistic or paranoid that even the smallest change can bring down the whole system,
right?
And that's what I try to tell the engineers is like,
hey, actually the smallest pull requests are the most dangerous ones because they're just like,
oh, can I get a quick review and we'll ship it and this is a small thing.
Those are the ones that bring the servers down.
So
Scott: A
Miguel: no
Scott: hundred percent.
Miguel: changes in Ocus,
like make sure that you are extremely paranoid.
and yes keep shipping but just think about what's the worst case scenario what what can go wrong when I deploy on when I launch when I when I ship this change I don't know those are part of the culture I guess
Scott: Let me recap that first and let's see if I have my,
Miguel: yeah
Scott: I think I missed the first one. I mean, I heard it, but I don't remember it in my head. And then it was be, what was the first thing you said? Something and then be pragmatic.
Miguel: be shipping
Scott: Always be shipping,
be pragmatic,
own it, and be extremely paranoid.
Miguel: Yeah,
Brad: And he also said customers first,
Miguel: customer obsession,
Brad: which I like.
Miguel: yes.
Scott: Oh, yeah.
Brad: Customers first.
Yeah.
Scott: That's right.
Brad: I just want to reflect a little bit on this.
I think that you started to tell the story of like values where your co-founder said,
hey, let's have some values.
And your immediate reaction was kind of like, that seems like like bullshit. And I mean,
like I can't count the number of companies that I've, you know, interacted with where it's like these value statements are.
are they just feel like platitudes right
Scott: Right.
Brad: excellence
Scott: Excellence.
Brad: yeah
Scott: Yeah,
Brad: yeah et
Scott: integrity.
Brad: cetera integrity right and but but what's interesting to me miguel is the fact that it was this third employee who you already worked with who already worked with your co-founder and you sort of felt like your answer would have been look you know us you know what you know you've worked with us you know our perspective on this
Miguel: And the idea that like, to me, I think.
The way to get out of platitudes and into like actually meaningful values is can you capture the authentic perspective of the founders and what they want the companies to be,
what they want that culture to be.
And it's less important like what those values are,
maybe.
Brad: Correct.
Miguel: And it's more important that whatever you say your values are.
Brad: They are consistent.
Scott: And it's
Miguel: obvious. You're consistent and you're obvious.
Like it really is like I can tell like the energy that you give off is like,
yeah,
of course we ship on Friday. If we've got an important customer that has a meaningful thing that's going to make a difference for them, then of course we're shipping it on Friday and we take ownership of that. We do,
you know, we are ruthlessly ruthlessly thinking about practicality.
and uptime and scale and and so those are our values and you can see it on your face that that's what you care about as a cto like if you had said instead like enjoy family time if somehow had been convinced that you know that that's what you needed to add to your values people would be like that's not miguel that guy's up at 3 a.m on friday fixing some customer bug
Brad: Well,
there's a couple of things to add there.
out there uh i mean i think uh well there's another fourth value that i didn't add uh which was the most controversial one because people didn't get it which is balance which is and we still believe it in any way like even even when making technical decisions and analyzing trades and stuff but the reason was because when we started the company both my co-founder and i were working like every saturday or sunday even and we were like okay this is going to be a very long journey let's make sure that we don't burn out and
But again,
this is one of those things that.
People can misinterpret and think like, oh, balance means that I don't need to work.
It's like, no, it means that if there's an incident or an outage or something and you stay up late,
then maybe you don't need to come to work next day or can come later and you're an adult and you need to do it. But again,
it needs to be,
people really need to understand what it means.
But another example is like,
we're very transparent,
right? My co-founder and I don't know how to lie and we said...
And even...
things like i don't know the best of updates they are shared with everybody else the cap table everybody knows the cap table how much money is in the bank all those things i send an update every every friday to the whole company about what i'm excited about and what i'm scared about and the good and the bad uh but we don't say transparency is a value right because it's one of those things that it feels it would feel dishonest it's something that people need to figure out if we are because there's different level of transparency too right uh but yeah i mean one thing another exercise of that
As we do, we have a channel in which we highlight when people do and I particularly like doing it for people outside of engineering when somebody does something that is probably not expected from them or something that is very customer obsessed or or ship something that people were not expecting. I always try to shout them out so that the rest of the company see like,
OK,
this is the type of activities that actually embody our values and you see them every every week.
pretty weak, right? And there there were example for people to find the motivation to be like okay these are the things that are rewarded and then it's another thing that you need to take into account to like it's part of performance to when you're doing performance management the cultural aspect plays a big role in the
Like you can be the best engineer in the world, but if you're not going in the same direction as the company or doing the right things,
then you might perform less than somebody that is probably not as smart or as experienced as you, but it's like solving a real customer issue and shipping every day, right?
Miguel: Yeah, totally.
Scott: So I wonder if you could tell us about a time where you and your co-founder could have been someone else in your company,
I suppose.
made a decision that was difficult in order to stay aligned with your values.
Right.
And I'm not thinking of a good example to give to spark it, but I know that I've been in a place where there have been, I've been, I've experienced my career times where, you know, somebody has said,
let's do this.
And, you know, as a leader, we've had to come back and say, no,
like we're, that's not aligned with our values and our values is this other thing. And as a result, we're having to choose a harder path, a harder solution.
Sure.
Sometimes it's that can range from saying no to a type of certain type of customer that doesn't meet the standards or no to how something gets built or I don't know what is if you had experiences like that where you've had to make difficult choices or a difficult choice.
Brad: I mean, it's difficult to come up with a concrete example because I feel like we have decisions like that every day pretty much and that's the beauty of having these things.
encoded in people's DNA's or like written down because people have a framework to make this type of decisions and some of them don't even escalate to us right
Scott: Mm-hmm.
Brad: I mean today even today we had a scenario and it's a little thing right but even somebody that is two levels below me knew what the right answer was most of our customers are self-serve we have a sales motion but it's not obviously like yeah we have enterprise and bigger customers like like
Like OpenAI, obviously they don't just go and click and put their credit card,
right?
This is a longer selling process.
We have a technical account manager and a customer success manager for the biggest enterprise accounts.
And there was one account that for whatever reason ended up, I don't know why it happened, but ended up having a Slack channel with us and they didn't have a technical account manager.
account manager assigned and some of them asked me like hey like should we really do this because technically they're not an enterprise customer and they don't have the right to have this and they're asking a lot of questions like should we send them to the standard send desk support system and not get the priority and it's like well and they knew the answer was like yeah it sucks and it's probably not super fair to other customers
but for whatever reason they ended up having a slack channel we need to we need to we need to treat them as if they were like what the customer obsession is like they have a problem right now let's solve the problem right now and then we'll figure it
Miguel: Yeah.
Brad: out the how it affects us in terms of contract value or whatever but right now we need to make sure that they are served so yeah things like that happen pretty much every day and then I mean I don't know like there's there's has been situations too in which yeah customers needed something right
right away for whatever reason or maybe maybe it wasn't even our fault right it most most of the time it's like bad configuration or they had an outage and they're missing data and whatever and they wanted us to do something for them we try to jam it's part of always be shipping and customer obsession it's like okay well this is they didn't pay for this but if we can make their life easier let's go and i think it's also part of like understanding that
sometimes for this type of thing especially for the one-off things first of all it creates a great it's a great customer experience people are going to remember this forever when you when you make them a favor when when they had a big trouble but also maybe they don't need like oh we need a perfect ETL system no they just probably need a CSV with the data that they were missing and we just like dump it and send it send it to them in a in a S3 bucket or whatever right so yeah it's making sure that
that people understand that it's not always what is the most elegant better technical solution for a problem but what is the fastest path for solving a customer problem that then we can iterate and make perfect but like again the biggest mistake here is always which is very common in engineering which is like oh let's build the most over-engineered perfect system that is scalable and then you
Yet it turns out that it doesn't solve any problem and people don't use it.
Miguel: Yeah, that's when you're being pragmatic and always be shipping and I can totally I can totally picture it like.
as soon as you were kind of walking through your values and you kind of told the story of like hey you might be like the world's greatest engineer but if you don't demonstrate these values then you're not going to be a fit here the thing that comes to my mind is the person that's like overly focused on the perfect
implementation or the or the more elaborate implementation or the like oh look you know this is the this is the right way to do it and if that right way to do it
isn't achieving the goals of being pragmatic or or you know being really focused on actual actual customer needs then it's like yeah look you're you're not going to be a good fit here right
Brad: Yeah.
Miguel: you're going to constantly just be butting your butting heads where we're going to be like no like
Brad: And that's another learning that I had too,
is that you want to have, you want your culture to be as welcoming as possible for sure.
But at the end of the day, like.
this is what makes a company unique and you need to understand that if you're trying to make a company in which like everybody fits and everybody is happy then nobody's happy really and there's things that are not negotiable and things that how we work and why people certain people love working here and other people don't and it's fine like there's you kind of feel terrible about that
Miguel: Yeah, I love it.
Scott: Well, there was something you said a few minutes ago that I really loved, which is you said
I asked for an example and he said well it's just a lot of small decisions and you talked about how it's you know not just you but other people on the team making these decisions and I love how those values you know they serve as guidance they serve as almost like guidance of last resort
Miguel: There
Brad: guys
Miguel: you go.
Brad: yeah
Scott: When you're doing something and you don't know what to do,
see if these help guide you in the right direction.
And
Brad: that's
Scott: I thought that was really great.
Brad: one of the people again i mean i guess i see it more clearly after many years but uh that's what people tell you know culture is what people do when the founders are not looking or whatever and it kind of is right like if you have those guidelines written down and it looks like okay well i follow this algorithm or whatever and kind of came up with a similar conclusion i guess and
You can't define that as a sculpture probably.
Scott: Yeah, it's terrific.
Miguel: I was going to maybe pivot a little bit and I kind of want to pivot to your first key concern of product market fit and and then we can rewind the tape about 20 minutes to you first uttering into into the presence,
the token genie, the AI genie. And
Brad: Yeah.
Miguel: I'm just curious,
as I think about.
revenue cat i think that it's possible this is my naive perspective that
Brad: Mm-hmm.
Miguel: you most you might be seeing sort of like the ai you know vibe coding boom as both a incredible opportunity for revenue cat
as well as a potential risk for revenue cat and i'm just kind of curious if you think about product market fit and the dawning of like everybody thinks they're a programmer what's your forecast what are you thinking about the vision of revenue cat in the new age that's
Brad: yeah i mean obviously anything that i say today probably is going to be outdated next week uh this is the right like again i i
Miguel: what's fun about
What about this game?
Brad: yeah
Miguel: It'll
Brad: yeah it's
Miguel: be outdated
Brad: okay i
Miguel: before the podcast comes out.
Brad: think and again i'm well i can i can talk about my views on the ai and how i i pass it off and everything but uh i mean it's it's frankly it's been great like the tailwinds that we've been having are
crazy for multiple reasons uh one is that most of the biggest models use us so their growth has been insane so therefore we grow automatically the second one is that there's a lot of old niches and old apps that didn't have any ai and now there's new players that are integrating ai into these apps and they're building new apps that are making a lot of money and they're better but also it's way easier to build apps that's that's the biggest change right for us was help
help developers make more money and before developers were we couldn't even expand it and be like okay developer is anybody that is working in a developer in an app or like even if they're a growth person or whatever now developer is anybody that can prompt pretty much so that's been pretty great the biggest concern always is like will you be able to tell
the next model if like build a revenue card version for me uh and i do think that there's still some defensibility i mean maybe for the small person no i think for the bigger one there's still like all the infrastructure and the critical like the reliability part of it the security too but also
uh we're not only doing that that was like the first the main goal but everything else all the other growth tools that we're having and like right now we're really focused on also using ai internally as part of the product and having agents that can actually help your app make more money and be able to automatically like the vision is that automatically it knows okay your app has a weekly subscription or like a monthly subscription with a week
week without one week trial but the pricing is not good for this country and let's run an experiment automatically for this particular country or only for android or only ios and then i'll analyze it and if it's good i'll auto promote it and change the prices dynamically things like that which it will we believe it will pay the software will pay for itself uh but yeah i mean definitely super interesting times right now i mean the nice thing too is like right now if you're building an app and you ask pretty much any llm and you ask
that's good okay I want to monetize my app they all tell you use revenue card that's a way to go so we were kind of lucky in that sense I mean it depends who you ask might have been lucky might have been all the effort that we put
building the brand all these years and all that bad uh
Miguel: Was
Brad: yeah
Miguel: Sam in charge of your YC class?
And did you basically get in good with Sam and therefore he's there?
Brad: actually he was there but i think it was the last batch and i don't think we were i don't think we ever interacted with him i think he came to one of the dinners and gave a talk but i think it was michael siable he was
still there uh garytan wasn't there yet but yeah no uh that was honestly like the the opening i think is an interesting one because this is how we actually got in a bunch of customers it's like we're essentially free for the indie developer until you're making 2500 so what ends up happening is there's a lot of developers that work in the industry and work at bigger companies that have side projects and they use us and
Miguel: Mm-hmm.
Brad: then when it's time to implement
in app subscriptions in their companies they're like oh revenue guard gave me a pretty good service and i don't pay them anything maybe if maybe the enterprise product works well uh
Scott: Yeah.
Brad: and it's a very good like when you have
The engineering team as a champion is a really great way to enter a company.
Miguel: Yeah, love it.
Scott: So can we talk about AI within your organization to go?
What's that like?
We've talked to everybody about this. We talk about it ad nauseum, literally the definition of ad nauseum till we're sick of it.
I'm just curious, what are you seeing?
Is your team using a lot of, how's your team using it? What's your guys?
To
Brad: One
Scott: your story.
Brad: thing that I'm quite happy about, even though it's weird,
I mean, I would have loved,
on one hand, I would have loved to be like,
oh, I'm the one that pushed people using AI and using all these tools and stuff.
No, the reality is like,
honestly,
nowadays I see myself more of a founder than actually the role of CTO because I do think that we have really solid managers and really solid directors and ICs.
and I'm just trying to work on what the biggest fire is it might be engineering might be even cross collaboration with product or sales or whatever right so the funny thing is when when all the I mean obviously I tried DALI and the initial version of chat GPT and all of that and it was like oh this is cool this is kind of impressive but it's a toy right and I'm sure there's going to be like again I know that there's no silver bullets I have been here long enough
uh he didn't expect it to be a revolution right so it was like okay this is a cool thing but there's gonna be a limit for sure like we'll soon hit a limit in like three four months and it's not gonna advance advance that that fast but the nice thing though is that as i said we have a very pragmatic team and they organically started trying things i was very open about like hey you can try whatever you want but as long as you share the results uh yeah you have
I mean not a limited budget but pretty much so people started playing with with Copilot or Courser with all the tools and and it was very organic that's that's the reality it's like people were feeling like oh okay this we tried this and it worked really well or we tried this and it works really great for our SDKs but it doesn't work that well for our back end or they saw it okay this person is a lot more productive why is this person they were curious why is this person a lot more productive what's their workflow let's
let's share that information so yeah we were very early on and we saw the results in terms of productivity very fast it's also true because our team is since we are remote we don't have that many junior people because that's a risk to especially at the beginning because the code that was auto-generated was look really good but some at the beginning we didn't solve the thing that it should was supposed to solve so it still required it was really good for like boilerplate or
uh auto completing code but not really designing stuff obviously it has improved a lot nowadays uh and yeah i guess we're at a point right now in which like obviously everybody is super productive we have even people that are not engineers people from product or or or design even opening pull requests i think well the two challenges that we have right now one is making sure that now we should
try to standardize it as much as possible because i don't think it's cool that people experiment but uh there's diminishing returns i think there's a few people that should be experimenting or they're very passionate about it but we should at least have a framework of like oh this is how we do most of the things and if you want to have an agent that is working while you're sleeping this is the way to do it and don't don't reinvent the wheel but also for the code we generated we started we set up a rule which is essentially anybody can open any pull requests
But you don't need to be able to write,
like maybe you were not able to write that code by yourself, but you need to be able to fully understand it,
which means that if you want to change a button and then the results, the cloud code or whatever,
or codecs gave you a...
4,000 lines pull request unless you are very confident that you can explain every single line then you're not allowed to open that one right and that means that you need to keep fighting with AI until it's very clear or you understand everything because the problem is that then it's a bottleneck on the reviewers right like if if if you end up trying to come up with a very simple change and then and then it turns out that there was a much easier or faster way to do it and that has
has definitely brought down the number of bad pull requests coming up.
Miguel: I think it's so interesting,
Miguel,
this is obviously something that I've been advocating for a really long time that if the reason I think.
I mean, you sort of said this earlier,
like the code early on, the code was written, but it wouldn't necessarily be solving the problem. Right.
And this idea that as a senior engineer,
you can read the code and you know whether it's solving the problem, like you can interrogate like you like your rule of,
hey,
don't open a pull request unless you really can argue that that's the right way to implement the thing that the pull request is doing. Right.
Brad: Yeah.
Miguel: And what I feel like I see is.
is the teams that are really accelerating with AI are the ones where everyone on the team can meet your.
pretty clear standard right there they could have written the code themselves but they had the agent do the work and they have no problem signing their name to that because they understood it
Brad: exactly and maybe with faster i can do more things in parallel but however i there's another interesting um phenomenon that i've been seeing which is that i mean it's the ai psychosis right like the ai always tells you like oh you're doing great this is amazing let's make it
Like it makes make it better right and it
Miguel: Right.
Brad: gives you this dopamine hit
Miguel: Oh my god,
I've built so much like in the past it would ha this would have taken me a month and I needed I would have needed three more engineers and now I'm able to do it in an afternoon and I'm going so fast this is great and that is problematic too because most of the times the AI is gonna tell you it's gonna tell you yes to everything so sometimes you're like okay and how do I make it scale ten orders of magnitude more and and then it will be like okay and let's add Redis and let's add another thing and then I've seen it like
We've ended up, people have ended up with big projects that could have been a Python script,
right?
And it's like, okay, well, this is really, really, really over-engineered and I get it, it's cool and the AI did it for you.
But at the end of the day, you need to be guiding it, right?
You cannot fully be trusting it because it might come up with an architecture that doesn't make sense for the needs that we have.
Brad: So here's something that I think, Miguel,
you might be allergic to.
I was just talking to someone on our team today who is not an engineer,
he's one of our TPMs.
I
Miguel: Okay.
Brad: think he worked earlier in his career as a software engineer and an engineering manager,
but at this company, I've only ever worked with him as a TPM.
And we have a bug reporting pipeline,
basically someone can go into Slack.
I think it's called a Slack workflow.
You basically get a form to fill out and it looks
Miguel: Yep.
Brad: at the bug and it pushes it into Jira.
And he said, I'm going to go see if I can connect into this thing and actually have it go straight from someone reporting a bug to creating a pull request.
That's just,
he's like,
as opposed to having this be a bug reporting.
tool let's have this be a bug solvent tool i was like okay that's interesting let's try it out see how that works now here we have a case where there's no engineer in the middle right it's just someone went into slack and said this is a problem i found and then a pull request gets made and then we're gonna have this big bottleneck of people having to review would
Miguel: Yeah.
Brad: you do that
Miguel: I mean, we're experimenting with a lot of these things, but I still think that it's not...
we're still not there yet because at the end of the day there's something missing which is i mean the context is what is missing right like if if they had perfect context about all your customers your historical problems uh the code base and everything yeah i would trust it but the reality is that that's that's not how it is right now and i've seen it multiple times right
Scott: Yeah,
Miguel: yeah
Scott: like just like that's my reaction is forget AI for forget AI for a second. OK,
let's say there's no such thing as AI coding.
Would you want a direct from a customer?
directly to an engineer to solve that one thing like you still have to adjudicate the bug like that's what bug triage is for somebody somebody needs to say like is that even a bug i can't count the number of times that i've seen a bug report i've seen bug reports filed by product managers that are complaining about a bug in the thing that they described where literally you could pull a product spec up from two months earlier where the thing that they're now describing as a bug
But was explicitly stated in the product requirements.
Miguel: yeah and again maybe it's not a bug maybe the software is working as intended or maybe it was wrong requirement right and you need to adapt the requirement
Brad: Well, so I think there's some interesting questions. One is,
you can still do triage but then how is it solved also you're you're basically getting a package now you're getting a problem and a solution to prioritize and validate not just a problem i don't know who knows if we're going to put it in production but he's like he said i wanted to try and i was like sure go for it see if you can make it
Scott: Well,
Brad: work
Scott: there's another company out there that did something similar, like it's a it's a AI assisted like telemetry package,
you know, that.
it analyzes your telemetry and then actually creates pull requests to fix whatever the telemetry was saying was wrong so like you're like you had a spiking 500s on some microservice or something like that and it goes and tries to create a pull request to fix the problem so i mean your tpm is not the only person that's out there saying hey is this a way we could use ai to speed up our lives and i and i think it's a cool idea i just think that
I just think that like to make to Melgo's point like you have to have the context about what the actual problem is and what the solution is and that context is not just about the code like clearly we need to have great the agent needs access to the code to have great content text but like I just think that you have to have so much like that's the part where I'm like convinced that like engineers we may we're going to see radical shake up in how software engineering works with AI
But the most important thing that a quality senior engineer is bringing to the table is the judgment of mapping the business problem to the technology in a pragmatic,
ownership,
customer-obsessed, balanced way.
Miguel: I think that's one of the biggest problems that is frustrating a lot of people because there's
In this industry, there were people that were like overly focused on like being an expert in one particular language on the synthetic, like they enjoy the craft of writing code and that's changing,
right?
And I do think that it's very interesting for the people that obviously for those people, it's not good times at all because they base their whole careers or their identity in that particular part of the software development process. But I think to me,
The actual type in the code is not necessarily the most important part of the software engineering side of things.
We're going to be able to do it more faster,
but you still need to be able to debug,
understand.
Of course, you're going to be able to do this faster and everybody is going to, every engineer is going to be able to act as a little.
tech lead or engineering manager with a bunch of more junior or middle engineers at their disposal for sure but that doesn't fully remove all the other tasks that a real software engineer is supposed to do in my opinion
Scott: Yeah, totally.
This has been this is a really compelling conversation,
Miguel.
I think you've really hit that.
Like, I don't think there's anything else we can say. Like, we basically landed on.
If your identity was all about the craft of writing a specific language,
then you're going to have some hard times.
But there's so much more to the job of software engineering.
And, you know, the story that you told of RevenueCat is a great example of like,
as an engineer,
you discovered.
a very compelling problem,
a business problem,
you put on your business mindset,
you had great essentially founder market fit because you knew the problem and you've created a, not just a technology, but a technology,
a business solution,
a culture that is.
obsessed with really providing value and if that's if every one of your engineers can be like that then it's like any anything you want to solve you're going to solve it
Miguel: that's what we try uh i mean i think so i think at this point it's most likely that the way we die is by suicide than anything else so hopefully hopefully if we keep if we keep hiding the right people and building the right things for the customers that's the other nice thing about serving developers is that
it's a very interesting user base because they have strong opinions and they're
Brad: No,
Miguel: they uh
Brad: no they don't.
Miguel: no but but it's super useful it's super useful because uh obviously when you do something that they don't like they're gonna tell you and it's gonna be very painful but at the same time it helps you improve the product but but but if they really love what you're doing they're also gonna tell other people and they're gonna be your biggest fans so it's it's been great serving serving developers for sure
Brad: Well Miguel,
thank you for kind of joining
Miguel: No,
Brad: us.
Miguel: thanks for having
Brad: I
Miguel: me.
Brad: really appreciate it. This has been delightful.
Miguel: It's been really fun.
Scott: Yeah, super,
super interesting conversation.
Awesome.
So RevenueCat sounds like it's an amazing service for anybody that is building subscription-based models in their applications,
and we'll make sure to link RevenueCat in the show notes, obviously.
Thanks again,
Miguel.
It was awesome talking to you. Thanks for coming on the pod.
This was a great conversation.
Miguel: Thank you very much. It was a pleasure.
Scott: All right, everybody.
That's an episode of How Many CTOs Does It Take Podcast?
And what do we say, Scott?
Remember to rate
Brad: Smash that subscribe button.
Scott: and review.
All right. Thanks, everybody.
This episode of How Many CTOs Does It Take Podcast was edited by Safran Epigow.
Our theme song was AI Generated by Brat.
Please follow us on all the social media platforms at at HowManyCTOsPod.
You can find us on YouTube, LinkedIn,
Instagram,
Facebook,
Threads, X,
TikTok,
and Patreon,
or at our website at HowManyCTOsPod.com.
And remember to rate,
review,
and subscribe on the podcast platform of your choice.
Thanks for listening.