EP 43 - Render - V1

Cold Open And Five-Star Ask SPEAKER_00 0:00 You don't really have product market fit until you're growing naturally. And that usually happens when your users are spreading the word. You really have to find founder market fit. I think that's crucially important if you're really in it for the long run. Because if you're successful, you're going to be in it for the long run. So you better like what you're doing. Otherwise, you're kind of stuck. Pablo Srugo 0:22 How long from zero to 10 million ARR? Like how long did that take? SPEAKER_00 0:25 Oh, it took a while. Three years. Yeah. I mean, from the founding of the company, certainly almost four years to get to 10 million AR. And like VCs wouldn't fund a company like that these days. That's product market fit. Product market fit. Product market fit. I called it the product market fit question. Product market fit. Product market fit. Product market fit. Pablo Srugo 0:47 Product market fit. SPEAKER_00 0:48 I mean the name of the show is Product Market Fit. Pablo Srugo 0:50 Do you think the Product Market Fit show has product market fit? Because if you do, then there's something you just have to do. You have to take up your phone. You have to leave the show five stars. It lets us reach more founders and it lets us get better guests. Thank you. What Product Market Fit Feels Like Pablo Srugo 1:04 Anrug, welcome to the show, man. Thank you. I'm really happy to be here. So uh you're on quite a ride. I mean, you were employee number eight at Stripe, which is a pretty crazy accomplishment on its own. And then you uh started render a few years ago, kind of 2018-2019, and you've raised $250 million. You just raised $100 million at a $1.5 billion valuation. So it's been quite the hockey stick ride. And we're gonna talk, you did a lot of things differently. So we're gonna talk a lot about how you you made every piece happen. But let's start with the early stage climax moment, right? Which is product market fit. Tell me, when did you feel like you'd found true product market fit? SPEAKER_00 1:44 Yeah, for render, there was definitely a sense of people saying amazing things about the product and then just wanting more. And before we had launched, everything was fine. We could ship things at our own pace. There were no customers asking us for things. And we took our time, we got the product to a point that we were proud of. And then when we launched, we suddenly started getting all these pulls from customers saying, Hey, I love this, but I really want this other thing. I love this other thing, but now I want this other thing. And it felt very much like we were just trying to keep up. And that to me is always a great sign of product market fit when your product doesn't have all the features, but what you have is valuable enough for people to truly invest their time in it and to take the time to ask you for more things. Because the worst thing that can happen is people don't care about your product, right? And then they just move on and they don't need new features. But when you build something that is incomplete that people are willing to try to use to pay you for, and they want it to get better. For us, that happened shortly after we launched in uh as part of TechCrunch Disrupt in 2019. TechCrunch has this annual competition, which is also shown in the HBO show, Silicon Valley. And we ended up competing and winning that show that year. Uh, not the show, the competition. That led to a lot of new users coming in, and all of these people wanted more things. They continued to be users, but they wanted more things because the platform was pretty early back then. But that was a first instance of like, okay, I think we're really onto something here. Pablo Srugo 3:34 Let me dive deeper on that. Like, I would agree that what you're saying is like a necessary condition for product market fit. The question to you is when do you know that it's sufficient? And you know, I'll give you an example. I was talking to a startup actually earlier today that I would argue doesn't yet have true product market fit. They don't have that like hyper growth that tends to follow from this. They do have users, they do have people that like the product. And so, I mean, there's a lot of times you put out products and nobody really cares. Obviously, that's the worst. But there's a lot of people that have a product that they'll say, yeah, there's an amount of users that do like it, they they use it, they love it, and yet they never get hyper growth. They never get the true outcomes of product market fit. For you, what's the difference between that and kind of what you are feeling? Word Of Mouth As The Real Test SPEAKER_00 4:14 I think people have to love it enough to tell other people about it. So you have to have this viral word of mouth growth. It doesn't have to be viral, it has to be word of mouth. And so every person who uses it is like, why isn't my friend using it? Or why am I not sending it to this other person who could also use it? And this doesn't happen with all domains, right? For a lot of products, you typically don't have other people who need the product. So for render, though, it was very clear because fundamentally we allow application developers to host their applications online. And when you think about it, application developers love trying new tools. And when they find something they really like, they love to tell other people about it. And it might not be one-to-one, they might write a blog post about it, they might write on hacker news about it. And so you have to create natural growth. You can't just rely on ads and feed people into the funnel. All of that is useful and necessary as well. But you don't really have product market fit until you're growing naturally. And that usually happens when your users are spreading the word. Pablo Srugo 5:28 And what would you say having been through it, lived through it, is the number one driver of word of mouth? Because I agree, if you get word of mouth, it's a huge tailwind for, well, as frankly, as long as you have it. It is a massive strategic, competitive edge, whatever you want to call it. But what do you think is the main driver of getting that? SPEAKER_00 5:47 I think it's a combination of all the different things that make your product sufficiently differentiated and sufficiently valuable for the right audience. So it can't be everything to everyone. You really have to pick who you're building for. And then you have to make sure that it's different enough from what already exists out there, because you know, you know, you might as well use the other product. What's special about yours? And then different in the right ways that creates value for your customers. So you can't expect different results if you're simply building what the other folks are building. So you have to think about what your difference is, whether it's developer experience in our case, or it's some combination of pricing and how all the systems, how all your different services connect to each other. It's the set of features that you provide at that price point. A lot of those things have to be collectively different. So people are saying, okay, well, you know, I've tried all these other things, but this is the thing that works best for me. And it's really important to identify who that customer is because until you do that, you can't actually build the differentiated product that that customer needs. So I would say a lot of startups end up making this mistake early on of trying to build everything for everyone. And I know that everyone talks about this mistake, but you have to make tough choices and you have to start with a segment that you think you can build the best product for and the most differentiated product Time To Value And Fast Deploys SPEAKER_00 7:24 for. Pablo Srugo 7:24 Based on many of the founders that I've interviewed on the show, I've got a bit of a theory, and frankly, from some of the founders that have told me themselves, like that time to value itself is a big indicator, leading indicator of word of mouth. I'm curious for your product. Is that true? Do you get value quickly? Like, where does a developer see the value? How do they see the value? SPEAKER_00 7:43 Yeah. So we optimize for people getting to running a live application as quickly as possible. So all you have to do is connect your GitHub repo and render spins up a server for you with your URL, all the certificates taken care of, all the settings. But you have to do basically nothing to get a simple server up and running other than connect your Git repo. And that to us is the fastest way in many ways to get a server up and running, which is why if you go to our website today, our hero image still says the fastest path to production. Pablo Srugo 8:20 What was the before and after? Like things have obviously changed a lot, but when you launched this in like 2019, 2020, what was the was the current state of affair you got to do all that manually, or like what were people used to relative to what you offered? SPEAKER_00 8:31 Oh, I think people were really used to having to configure a bunch of things. Yeah. I mean, it depends on what you were using, but like AWS was and kind of remains a nightmare if you want to spin up a simple server. And then there were some tools that worked for the front end. I think Netlify and Vercel at the time were good for the front end. But there was nothing that lets you spin up this combination of a simple server really quickly along with a database and also a let's say a Redis instance or a background worker, all of that together, especially at a reasonable price point and with modern features, like things like private networking built in, things like HTTP3, HTTP 2 protocols built in. So there were some other tools, older things that had been around for a while, but they were kind of stuck in the past. And so modern developers really responded to what render had to offer, and they still do, and that's still driving our word of mouth. I mean, we're signing up hundreds and hundreds of thousands of developers every month. And that's all word of mouth. We're not driving that through ads. Pablo Srugo 9:39 And to be clear, even back then, that would mean you go from doing that manually, which is not just takes a long time, but is just like annoying stuff that's preventing you from getting your app to production, which is what a developer, whether doing it for themselves or somewhere else, like that's what they want to do with the thing they've built. And now you can just you connect your repo, it's live, presumably in minutes. Like, is it that quick? Or was it that quick? SPEAKER_00 10:00 Yeah, yeah. It's it's it's less than a couple of minutes in a lot of cases. And I think the main thing that render gives you when I think about it, isn't just the ease of getting started. It's also the reliability, security, stability that you need as your application scales. So there's a bunch of platforms out there that'll make it easy to get started. And when you need features, when you're getting more users, when you're getting production scaling, then they are either not reliable or they don't have the features, or something else happens and that forces you to migrate away to something like AWS, and then you have to build everything yourself. The render promise is that you don't have to, that we continue to build capabilities into our systems. So you can start out at paying us $7 a month, but then you can also become a company that is so big that you're paying us millions and millions of dollars every year, which companies do now. Pablo Srugo 11:00 That makes sense. And you know, I'm I'm driving at the time to value thing because I think what you're talking about now is what affects usage and retention and expansion and all that also critical thing. And you you mentioned earlier the difference between virality and word of mouth, right? Like virality, social network, you need other people on that product to make it better for yourself. Word of mouth, you don't really get anything, you're not doing it for the you know, the referral bonus points or whatever, generally speaking. You're just doing it because you you want to be the first to know. You want to tell your friends, you want to help you, whatever it is, but it it isn't like a clear transaction. So when do you do it? You do it when you're so wowed by the product so quickly, and you expect the person you refer, you tell about this product, they're gonna be wowed quickly. Like if you know they're gonna have to onboard for three weeks or two weeks or even four hours, uh, you're like, I yeah, you maybe say, you know, try this thing, but it's gonna be a bit of work. You know, like you you don't want to be the guy that whereas if you know, hey, you're gonna do this thing and right away you're gonna see value, you might tell 10 people, guys, you have to try this thing. And that's you know, that's just one thing the founder can always think about is whatever your longer term value is, how do you get them to, if you really want word of mouth? It's not gonna come from the referral incentives almost never. I mean, Dropbox maybe, but rarely, right? It's it's gonna come from getting somebody to that woman quick that they organically just want to do it. They want to tell their friends because the the social cost is low. SPEAKER_00 12:21 Yeah. However, there are counterexamples where uh time to value was actually really high, uh, but word of mouth was awesome. And you know, the canonical example here is superhuman, the mail app, where you actually had to go through an interview before you got access to it. And I I don't think you have to do that anymore. And the app has been acquired or merged with someone else. Anyway, but the point was everyone was raving about superhuman at one point, but then you to get in, you had to get on a call with someone and spend 30 minutes to actually get access to superhuman. So that's a very different kind of setup. Pablo Srugo 13:03 Very counterintuitive, yes, that's true. I mean, for every startup rule, there's there's a lot of exceptions to it. Founder Market Fit And Picking A Problem Pablo Srugo 13:09 So now let's let's go now that we know kind of where where that moment was where you where you felt like things were working, you know, we'd love to go through the story a little bit, especially the before. I mean, why do you decide to start a company and what what was kind of the original, the idea? What's the origin story here? SPEAKER_00 13:26 So having been that early at Stripe, and you know, I stayed there for almost five years, I was at a point in my career where, you know, I didn't really have to do anything. I didn't have to work. Stripe had done really well. And so I asked myself, how can I best spend the rest of my life? And it wasn't just me. My wife and I both sort of asked this question of us together. And I think the answer was we would like to contribute back to the world in a way that we're excited by. And for me, building things and building teams and organizations was and remains incredibly exciting in the service of solving a large problem. And I spent almost a year and a half thinking through fairly deeply which problems would appeal to me enough so I could spend ideally the rest of my career on them. And I looked at healthcare, I looked at real-time infrastructure. Pablo Srugo 14:26 I'd love to go deep on this year and a half because it's often skipped and it's exceptionally important because then a lot of things come out of that. Like where you start is the end point of that year. So we'd love to kind of go through that in a good amount of detail, just how you thought about it, how you broke it down, why you looked the space that you looked at, and so on. SPEAKER_00 14:45 Yeah. So one of the ways in which I started exploring these domains was okay, well, what are the big problems out there right now? And what can I do to help? Right. Like it has to be the intersection of my talents and skills and interests and what the problem needs to be solved. And you know, by some measures, solving world peace is perhaps one of the biggest problems there is, but I'm not the right person. I just didn't think I was the right person to do that given everything that I'd done. And it wasn't interesting in a way that I would, I think, find like personally fulfilling on a day-to-day basis, even when things are not going well. And so that's what you have to think about. Okay, are you working on something that you are excited by and will continue to work on even when things are not going well? And are you going to get up every day for years? Like in the best case, many decades, uh, but in the worst case, at least a few years, uh, assuming you raise funding for enough of those years. It doesn't matter how successful they are on the outside. Pretty much every company is chaos on the inside when they're growing. Lots of chaos all the time. I saw this at Stripe, I see it at Render. You ask any hyper-growth company right now, there's tons of chaos. Pablo Srugo 16:08 I love how from the outside, from the headlines, you always just think it's like a smooth, especially if you haven't done it or you're just starting like smooth up into the right, I would love to be that, and you would love to be that. But when you're in it, it feels very different. And sometimes when you grow so fast, your runways get tight, and you know, the the difference between making it really big and actually just failing might be closer than you think. It's it's a pretty crazy world inside there. SPEAKER_00 16:29 Oh, yeah. When you look at all these companies that eventually make it, there are several times during their journeys when things could have gone very differently and they would have shut down. So going back to what I was doing in the year and a half, I was really trying to find that problem, the domain that was big enough, ambitious enough. Uh, because if it's not big or ambitious, then you don't have to spend a lot of time on it, right? Like you you build it and you you're done, you sell the company, whatever. And if it is big enough, ambitious enough, then actually spending more time on it can get you outsized rewards because your work compounds. And so every new thing, for example, that we add to render, now it's there. And now it's there for the next decade of or the next several decades. Everyone who uses render will have every new feature we add, right? Like it's something that we keep building, and it's there's a lot to build because also the way people develop applications keeps changing. And how do we help them regardless of how they're building their apps? Earlier it was traditional apps, these days it's AI apps, and we want to continue to enable the platform to support application developers no matter what it is that they're building. And not just application developers, these days it's also agents. How do we make the platform work really well with the coding agents that every developer is using so they can do whatever it is that they're trying to do much faster? But anyway, so I was going through this. Um, I looked at healthcare for a while, learned everything that I could about healthcare, and then realized that I was not going to help solve healthcare through technology. And I wasn't really the kind of person who was happy to have like three-year deal cycles with large hospitals. I just wanted people to start using the product immediately and get feedback and iterate on it and like continue to build great products and win on the basis of that. Healthcare is not that. Pablo Srugo 18:27 I also think, by the way, just to pause on that, like, I think that that's a pretty classic failure mode of some of the more ambitious founders, which is you obviously you start with the biggest problems. And I think somewhere where you can add value is a pretty classic thing. But I do think people forget a lot of times, or I've seen this before, technology often is not the solution. When you really dive deep, you realize, oh, there are other problems that are tech might address this stuff on the edges. It's not going to fix that. And so you're tackling a big problem, but only the small little pieces of it, and it's a mismatch. SPEAKER_00 18:57 Exactly. So I sadly stopped spending time on healthcare after a few months. And then I looked at a few other domains, but then another thing I looked at became interesting. This was very early when deep learning was just starting to become a thing. And there were people online who were trying to get their deep learning setups on AWS when there was just one GPU type available in the cloud and AWS offered it. But you needed to set up your NVIDIA libraries and all the other libraries on top in a way that was very finicky. And so, just especially if you were a data scientist trying to do this, it was pretty much impossible for you to do it on your own. And I was taking a course on deep learning online, and the person who was teaching the course, he had like a lecture that spanned two or three weeks of work to get this GPU-backed Jupyter notebook online. So the data scientists could actually work on the things that they wanted to work on. And I thought that was a big waste of time for everyone, obviously. And so I ended up building something that gave everyone a single-click Jupyter notebook in the cloud backed by a GPU. Pablo Srugo 20:12 This was just as part of the course, like you did it for your the classmates sort of thing, or you did this as a product? SPEAKER_00 20:17 I mean, I started building it for them, but I built it as an independent product. Got it. It actually took off. Again, through word of mouth, because it was so easy to use. I quickly got to like 10,000 data scientists on the platform. Wow. But I realized after spending some time on it, that I care more about the needs of application developers than those of data scientists. And so I could have continued to focus on data science infrastructure, or just, you know, eventually that would have become AI infrastructure and so on. For me, it felt very clear that the broader problem of just getting anything online was still unsolved in a lot of ways. Pablo Srugo 21:03 Was that more personal or was that more market size driven, the decision to focus on application versus data science? SPEAKER_00 21:10 I think it was more personal because I'd never been a data scientist myself. And I knew deeply what the issues were around application development. And yes, the market size may have been bigger, but who knows? Because these days, the market size for AI infrastructure. Pablo Srugo 21:30 Yeah, it's gone pretty big. SPEAKER_00 21:32 Exactly. So so again, it you really have to find founder market fit. I think that's crucially important if you're really in it for the long run. Because if you're successful, you're going to be in it for the long run. So you better like what you're doing. Otherwise, you're kind of stuck. So I did all these things. I kept getting drawn to infrastructure and I kept getting drawn to productivity and especially developer productivity. And that to me was a realization of Like, okay, well, I keep coming back to this. I guess I need to solve this problem of application developers putting their apps online. And I realized it was a pretty big task. It was very ambitious over the long term. I was going up against the hyperscalers. I was going to go up in a very crowded market, but it was a very large market. And it wasn't serving application developers well. So there are very large markets where some people are served really well, but there's a whole underserved segment in that market that is being served somehow suboptimally. What was happening and what still happens a lot with the hyperscalers is in every company you end up building some sort of DevOps team that manages the nitty-gritties of the hyperscalers. But all they do is give you a sort of poorer approximation of render. Um so the application engineers don't have to worry about infrastructure. Pablo Srugo 22:57 I'm really worried because listen, like you've been listening for like what, 10, 20, 30 minutes now. Clearly you like it. And the thing is, the next episode is way better and you're gonna miss it. You're gonna miss it because you're not following the show. Why Hyperscalers Don’t Build This Pablo Srugo 23:10 So take your phone out and hit that follow button. I have a big question on this because some of these problems, like however you get to them, may be non-obvious. But then a problem like this, like look, I'm just trying to pull my way back to 2019, right? And you come to me and you say, you know, I've got this idea and I want to make application developers go to production with like one click. It's kind of one of these ideas where you hear it, you're like, well, yeah, of course. You know, if you could do that, like no-brainer, right? My natural question is you mentioned the hyperscalers. Don't they want people to spin up applications as fast as possible, start using compute, and maybe some of those grow and they use more compute? Like, why wouldn't they have invested in making this process as smooth as possible? SPEAKER_00 23:49 So at the time I had some theories, and I think I know the space better now. And it all comes down to organizational DNA and organizational incentives and where the money is coming from for these people. And for AWS and GCP and Azure, all the money is in massive enterprise contracts with companies that have massive DevOps teams. So guess who they're building for? They're building for DevOps engineers. And they've tried, they've tried to create products for application developers, but they probably don't put the right people on it. They probably put the right people on it, but these people don't get the resources that they need. Uh, it's not an organizational imperative. And they always have these low-level products, right? And so even when they build the higher level products, these products don't solve all the problems because you can always go tell the user, well, if it doesn't do this, then just use Kubernetes because you can always use Kubernetes. And for render, that was never an option. We said, look, if you have to use Kubernetes for something, that's a failure. That's a thing that render should fix. Even though we can offer managed Kubernetes, the best managed Kubernetes in the world, to anyone, given everything that we've done over the last several years, we don't want to. We want to give people the power and the scalability and the flexibility of what they would get from something like Kubernetes, but at the application layer. So they don't have to think about what's so all the configuration that's needed, because that's not part of what they're trying to do. They just want to get their applications online. And so it's very cultural is the short answer. And it's not like they haven't tried, but I think for them the market isn't large enough. Pablo Srugo 25:40 It's a great answer, and I think a very true answer. And for some reason, an answer that oftentimes, unless it comes from like, you know, a proven exited founder, then it's whatever. But a lot of times, you know, these kind of why wouldn't Google do it? Why wouldn't ChatGPT do it these days? Why wouldn't OpenAI do it, Anthropic do it, whatever? Like, and the answer is just because like they could, they 100% could. You know, a lot of times, oh, it's gonna take them long. They could obviously do it, they just won't because like you can only have so many high priority things that get the resources, that get the mind share. You only have so many, even these big companies, like true leaders that can really divert massive resources. There's only so many, and they they have to go a certain way. And so if you're taking them on an area that is not the top importance, you're not really taking on AWS, you're taking on like this small team with a limited budget with like the you know 50th best PM on it at AWS. And that is uh that's actually doable. SPEAKER_00 26:35 Absolutely. So, yeah, so we're not trying to build out massive data centers and you know spend 80 billion dollars on buying more GPUs and megawatts of electricity. That's not who we are. We can't do that. Uh, that's what AWS is really good at, and that's where they're competing with Google and Microsoft and all the others right now. And so our goal then is to continue to focus on application developers and like I said earlier, increasingly agents that developers are using, and just focus on helping them run their applications in production with ease, with control, flexibility, scalability, and reliability. MVP To TechCrunch Disrupt Launch Pablo Srugo 27:16 So now we've got kind of the idea and how that came about. Walk me through launching the product, you know, the first users, and then I don't know if you did a beta or how you did it, but that whole structure of from you know idea to MVP to like really launching. What was that like? SPEAKER_00 27:29 Yeah, well, first you have to hire people. So I'm an engineer. I built a lot of the early stuff myself and continue to build the platform even after we had a team. Did you raise once you had the idea or did you raise later? Pablo Srugo 27:40 How did you structure that site? SPEAKER_00 27:41 No, I raised after I had a working version, and then I went and hired uh our first engineer who's still at the company. And then we built out a team of total four people, and we said, okay, this is it. This is a team that we're going to use to launch the product. So we had a designer and three engineers, and that was it, including me. And we worked on the product for well over a year, almost, I guess, two years, got it to a point where it had a lot of the requisite features that you would expect from something like this. I was still pretty underfeatured at the time, but that's when we got to TechCrunch Disrupt in October of 2019. And that was when we sort of really launched it to the world. And we got a lot of signups, a lot of attention. A lot of it fell away because we didn't have a bunch of features. And that's fine. Pablo Srugo 28:36 And how did you do that? Like, was it besides tech you went TechCrunch Disrupt? You know, you you ended up winning that, that gets you PR. Did you do a bunch of other things as well? Or was that really the only kind of launch move? SPEAKER_00 28:47 I think that was the biggest launch move you can have as a startup. And so then we relied on just word of mouth. And in the very beginning, actually, we just enrolled our friends. I went and spoke to everyone I could, and I was like, you need to move your site to this. And often I just did it for them. That's how you do it in the beginning, right? Pablo Srugo 29:06 Yeah. How do you know talk to me about that? Because this is like really, really important at a certain point. You know, like if you've already got an app and it's already in production, the valve pals maybe not as clear. Like you have to find there's a point in time where it's like, holy shit, I really need this. And then you do the work and you got it, and you're like, yeah, okay, I guess how did you work that? Like, that's not that simple. SPEAKER_00 29:24 No, just like, look, this is the future. You're using an antiquated product, and this is gonna be better for you. Pablo Srugo 29:30 Like hand-to-hand combat. Like you would just convince them you you should just switch. SPEAKER_00 29:33 Yeah. Pablo Srugo 29:34 Is that where the credibility comes in? Like that's you had a relationship, they had credibility, they're like, okay. SPEAKER_00 29:40 That was part of it, certainly. But then also I think that our product was meaningfully better in certain ways. And so I think it was a combination. And yeah, I I think developers often want to use new things, and that always plays to our favor, or it did back then. And I wish we had more users early on, but I I think the users we had were really helpful because I could get real feedback from them. And some of them put very critical things on the platform. And, you know, looking back, if I were them, I would think twice, knowing everything I knew about render. But you know, the Pete Buttigieg campaign ran all of their infrastructure on render in 20, I think it was 2019. And they did not have the smoothest of experiences, but it certainly told us how to scale to national level traffic. Pablo Srugo 30:32 You Getting To $10M ARR The Hard Way Pablo Srugo 30:33 know, let's go deep on that because you, if I understand correctly, you got the 10 million AR with no marketing spend and no freemium. Like you literally, you had a free trial and then you have to, you know, convert to paid. I'm thinking about this from the perspective of a founder. One of the key things that we've hopefully established so far is nothing works unless you have a product that drives a lot of very clear value, hopefully as fast as possible, because that is the core that drives word of mouth. But what else did you do or what did you wrong, right, on that path to 10 million AR? Because, you know, not spending on marketing and not having freemium, like that's a very unique place to be in. SPEAKER_00 31:10 I mean, honestly, I made a mistake and I think we should have had a free tier sooner. Everyone else had a free tier, and we decided not to have one because we thought that we really wanted a certain kind of persona where people would come to us for real production applications, and they would get enough in their first month to try us out. But that was severely curtailing our total signups because a lot of people would never try something, even with a trial, if they have to pay anything at all. And so we introduced our free tier after we raised our series A. Pablo Srugo 31:52 How long from zero to 10 million AR? Like how how long did that take? SPEAKER_00 31:55 Oh, it took a while. We reached 10 million around maybe the end of 2021 or the beginning of 2022. And you launched 2019, so like two to three years? Three years, yeah. I mean, from the founding of the company, certainly almost four years to get to 10 million ARR. And like VCs wouldn't fund a company like that these days. Pablo Srugo 32:20 Yeah, these days, but these days everything's cute. You don't want you can't you can't compare it to these days. In normal days, even in those days, I mean, you know, from launch to 10 million in in three years, I think was because you know, we used to talk about you hit a million, then you triple, you know, triple, double, double, that's kind of gone. But you're more or less on that path. SPEAKER_00 32:36 Aaron Powell The other issue was that we hadn't quite focused on building efficient infrastructure from the beginning, because we really just wanted to get applications on render. And then when we started offering a free tier, our burn increased significantly. And then we also realized that we had to focus a lot more on making our infrastructure more efficient. So we were just spending less on the cloud and not giving away a dollar for pennies. So a lot of our work in 2022 and some part of 2023 was less on building features and more, and it was still a small team, but was less on features and more on just making the system more efficient and having our cloud costs be more aligned to our revenue. Pablo Srugo 33:26 But you know, one of the trade-offs that you must have done, I'm curious on your thoughts on it, are like you've put this product out, people love it, you get organic word of mouth. You can always drive more growth through not just freemium, but through spend. I mean, you could spend into it, but you always have this trade-off of do I focus on spending, getting more people more awareness, more whether it's PR, payment, whatever it is, there's always a way to drive, you know, spend and get more growth. Or do I just focus on investing that time and resources into my users and building the product and the features? There's always this trade-off. Like it seems like you focused a lot on the latter. And I assume that was by design strategic, but maybe tell me more about the thinking there. SPEAKER_00 34:02 Yeah. So the product just still needed a lot of work to fulfill everything or most of the things that our customers wanted from it. And when you're building a full platform, you can't just offer half a platform and make people happy, right? Like they need so much out of the cloud. Like imagine replacing AWS with render. There's a lot that you have to build. At the same time, we also weren't necessarily positive margins on every user we were bringing on. So we need to fix that to reduce our burn so we could actually spend money on marketing that would lead to positive revenue as opposed to increasing our burn rate. Every new user was actually increasing our burn rate at some point. And we had to get out of that before we invested in marketing. It's another point. Pablo Srugo 34:54 We talked earlier about the difference between how some of these hyper-growth companies are so close to failure sometimes. And this is another classic example. Like, you know, you might offer a service that you know could be profitable, but it's not profitable. And actually, the faster you grow, the more you burn, right? Do you remember like, you know, PayPal early days are like there's, I mean, there's going to be a lot of Uber or whatever. There's a lot of examples of this. It's more common than you think. But there's always this trade-off of do you optimize for the margins or do you optimize for the growth in the user experience? And you at some point you have to make that shift. But you know, it's it's this dance. It's this dance because if you if you overdo it on one side, you won't get the growth. You overdo it here, you run out of money. So you you gotta you gotta play with that as you go. SPEAKER_00 35:34 Yeah, exactly. And so we actually had to raise prices at the end of 2022. And it was not a very popular decision even within the company. But I knew that if we didn't do it, then it would mean that we're just not running a sustainable business and it would not be the right long-term thing to do. So we raised prices in January of 2023, and uh surprisingly, we did not see a ton of churn, but our growth did slow down. So that was a trade-off that we had to make at the time. Pablo Srugo 36:04 I was gonna ask about you know team size, like it's you know, you're four people when you launched, so you're very lean. When you hit 10 million ARR, like you know, end of 21, early 22, more or less, how many people were you? We were probably 25, 30 people, something like that. And then the other thing I wanted to talk on because something else that you did differently, which is you've got a lot of users. I mean, today you have I think six six million developers, is that right? SPEAKER_00 36:24 Yeah, more than six million folks on the platform. Pricing, Burn, And Cloud Cost Reality Pablo Srugo 36:27 You know, back then uh you you had less, but you probably had you know tens of thousands, hundreds of thousands of developers, and you for a long time had no support organization. You didn't have really a customer success or or support. You had your engineers kind of fulfill this function. Tell me more about how you structured that, why you did that. SPEAKER_00 36:44 Yeah. So in the beginning, it was actually really helpful for engineers to hear, for all of us, including me, to really hear directly from our customers who were also engineers. And in many cases, we were able to fix the problem right away. And that really quick feedback loop made folks really happy, even though they had run into a problem. And it made them champions. And I think that was really important for us to do and it it made a lot of people long-term happy users of vendor. And we we kept doing it until it felt like we just had too many users who needed to talk to someone. Pablo Srugo 37:22 And when was that more or less? Like how and how many employees or or AR did you did you start really hiring like a support team? SPEAKER_00 37:28 I think we must have been around, yeah, 25 or 30 people. Okay, around 10 millionaire. Wow. Something like that. And then we hired some support folks who uh this was like right after our CSA, I guess. And we started building out the support team. But even the support team was, again, very small. And even now it's very small. With six million plus developers on the platform, we're able to manage support with less than 10 people. Pablo Srugo 37:55 How did you structure that? Like tell me that that road to 10 million and and your engineers are the ones doing support. Like how did you set that up to make it work? SPEAKER_00 38:03 It was a rotation. So in the beginning, we were thinking about maybe daily rotations, but then we quickly realized that you know the context switch is just so disruptive that it would be better to have an engineer do support for like an entire week and and then do you know as much as possible, and then the next person would take over. So you would effectively say, This is my support week. I'm not doing anything else this week. I'm not coding. So you in many ways you would be out an engineer at all times. Pablo Srugo 38:34 There's the the example you gave of wowing customers by being able to change something very quickly, which I could see then not just driving retention, but even word of mouth. But how did you see that internally as you're thinking about the product roadmap and you're having, you know, the the regular meetings that you have on product roadmap? How did this exposure, this because every engineer would have rotated through this, and then you have these discussions about, okay, Engineer-Led Support As A Growth Lever Pablo Srugo 38:55 should we build this, should we build that? How do you feel like that kind of fed into those meetings? SPEAKER_00 38:59 Yeah, it really helped. It really helped to hear directly from customers and build true empathy. And when you're doing support regularly, you kind of develop back then we didn't have AI classifying issues. So, you know, we did just did it manually. And you kind of develop intuition for the things that keep coming up, and that drives the priority and importance of your roadmap and which ones you take on first. Pablo Srugo 39:26 Yeah, I have to imagine, especially for product like growth type product, like you like your, I mean, the product is your growth engine, it's always important. I mean, great product's always important, but you know, frankly, depending on your your sales motion, how you go to market, who, you know, is the user, the buyer, like all these different things, it can matter more or less. I mean, but when your product, when you're doing product like growth, you're not even spending on marketing, your product is the growth engine, it's you know, the o the only thing that matters. And so, you know, I just think about like when I used to have those kind of product roadmap type discussions internally, and and even when I look at the the companies I work with, I mean, you know, the CEO, the salesperson, they've got this edge, and and the salesperson's often not even in those meetings. So it's like, but you know, the CEO in the early, early days is almost the only bridge, you know, and you're hearing the engineers and what they want to do, and the designers, what they want to do, and and the marketers, maybe, and you're the only person that can kind of bring that voice of customer. But you can imagine a world where you're having that discussion and everybody at the table has a firsthand opinion, right, of reality, how much better those discussions are and and you know, the outcome of that should really show up in the product, not just what features built, how you built them, everything about it. Absolutely. SPEAKER_00 40:32 Yeah. And it did. And even after we hired support engineers, we we don't have like level one support where folks are not technical. We only hired people who were able to understand coding and were able to like actually even code, but they weren't coding all the time. They were mostly answering technical support questions and helping customers with sometimes maybe even with their applications. And so we made sure that the people who were answering customer support requests had enough technical grounding to then give the right kind of feedback to the product team, to the engineers. And so they would bring these things back to the team with a filtered lens. And they would actually have really good suggestions on how to fix a problem, even because they'd seen customers go through different versions of the problem. And so they they could actually sometimes come suggest a solution that would serve multiple people at the same time. So again, it came down to like who you were hiring and what kind of profile you were hiring for. And I think we definitely made the right decision to hire support engineers as opposed to first line support. AI Apps, Agents, Workflows, Sandboxes Pablo Srugo 41:45 And then maybe the last question, because you're a pre-gen AI company that is still, you know, doing really well, kind of post-gen AI. Like, you know, there's three buckets. Like there's the ones that are clearly, I've got a company, portfolio company that they were always using AI, and then when AI got better, they just exploded. Like it just went, it took them up, it was a crazy way for them. There's other like classic B2B SaaS companies like you know, the SaaS Apocalypse that are clearly suffering, and there's some that have no impact. Like where AI just didn't really change fundamentally their business. What camp would you say you're in? And and then how have you kind of adapted to this, to this AI world, like if if at all, like if it's even been a big change for you? SPEAKER_00 42:19 Oh, yeah, it's been massive for us. Uh, we're definitely in the first camp. And that's because fundamentally, the number of applications being created has ballooned, exploded. And people are able to build things now that they always wanted to build, but didn't have the time for, the resources for. And I'm not even talking about people who don't know coding. I'm talking about people who know coding, who had all these pet projects and who wanted to build these things and now they're able to. And it's they're able to do many of them. And the same thing is happening within companies, where companies wanted to build these tools and now they're able to. So so much more software is being created, and a lot of it needs to be hosted in a way that is largely self-serve, because the DevOps teams within these companies either don't exist because these are earlier stage companies, or they're so stretched by all the engineers writing more software, all the engineers creating more pull requests, and the CI systems are no longer working. And there's only so many new applications that as a DevOps team, you are equipped to put in production. Because in the old days, you barely put like one application in production over a period of a quarter, if that, right? And now you're being asked to do everything. And so what we're seeing is more and more people, more and more companies are turning towards platforms, self-serve platforms like render instead of their DevOps teams and saying, look, we just want all our builders to have access to self-serve solutions that are also enterprise friendly, that are also giving us a level of control, a level of observability, compliance, security. And then there's just a bunch of builders who love. Of what we do and who rely on us to keep their applications, side projects, whatever it is, online. And so we've seen as of the end of 2024, we just started seeing a lot of traction and many, many, many more applications being deployed to render. And then that continued through 2025. And then we saw a huge spike, bigger than anything we'd seen before at the beginning of this year. Because a lot of people found that, you know, the latest version of Cloud Code and Codex. Pablo Srugo 44:33 Oh, yeah. When you when you can walk your dog and talk to Cloud Code and have it build stuff for you, it's you're gonna build a lot more stuff. SPEAKER_00 44:39 Yeah. And so our revenue has just changed. It's like even at a much higher scale of revenue, we're growing much faster than we did before, which is great. And then one other thing has changed, which is the kind of applications that people are building is changing. And so they need new primitives. And they need things like render workflows, which is a way for you to run agents that need to go through a series of steps. And you need to make sure that each step can be retried, that you have concurrency limits, and then you can sort of observe each step, and you can have a parent task and a bunch of child tasks. And so we built that product. It's going to be in GA by the time this goes live. And then the next thing we're building is sandboxes. Because again, you have a lot of code that is machine generated and you want to run it in a contained isolated environment. And you want to do that at scale. And guess what we've been doing? We've been running untrusted code. Because from our perspective, code has always been untrusted because we don't know what the customer wrote. And so we've been doing this for ages at a scale that is higher than any sandbox providers right now. And so we think that will be our sandbox products are going to be really powerful and scalable for what the industry needs right now. But more generally, we are expanding render to serve the needs of people who are building AI apps and agents. Because again, it goes back to serving the needs of application developers. And if they need us to build more primitives for helping them build these agents and deploy them faster, then that's what we're focused on. That is actually what we're doing Ambition As The Founder Advantage SPEAKER_00 46:14 right now. Pablo Srugo 46:14 Perfect. Well, let's stop there. Let me ask the last question we always end on. What would be like your number one piece of advice for an early stage founder that's just in that early phase of finding product market fit? SPEAKER_00 46:25 I would say something that I may have said earlier in the interview, which is I think all startup problems, all industries are hard and somewhat equally hard. So go for the most ambitious version of what you're trying to do because it's not materially that much harder than the less ambitious version. And the more ambitious version is actually going to help you hire more interesting people, people who want to solve harder problems. It's probably going to help you with fundraising because the market might be bigger and it'll just be more interesting. Perfect. Pablo Srugo 47:00 Thanks so much, man. SPEAKER_00 47:01 Really appreciate it. Of course. Thank you. Thank you for having me. This is great. Pablo Srugo 47:04 So Final Share-The-Show CTA Pablo Srugo 47:05 picture this it's months from now, years from now, and one of your founder friends, or really close founder friends of yours, guess what? Their startup went bankrupt. And it turns out, if you had just shared the product market fit show with them, they would have learned everything they needed to to find product market fit and to create a huge success. But instead, their startup has completely failed. You have blood on your hands. Don't let that happen. You don't want to live like that. It is terrible. So do what you need to do. Tell them about the show. Send it to them. Put it on WhatsApp. Put it on Slack. Put it where you need to put it. Just make sure they know about it and they check it out.