He quit Stripe and hit $10M ARR in 4 years - with $0 marketing spend. | Anurag Goel, Founder of Render

Anurag Goel : 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 : How long from zero to $10 million ARR? How long did that take?

Anurag Goel : Oh, it took a while, three years. Yeah, from the founding of the company, certainly almost four years to get to $10 million ARR and VCs wouldn't fund a company like that these days. That's Product Market Fit. Previous Guests : 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. Product Market Fit. the name of the show is Product Market Fit.

Pablo Srugo : 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 out 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. Anurag, welcome to the show, man. Anurag Goel : Thank you, I'm really happy to be here. Pablo Srugo : So you're on quite a ride.

You were employee number eight at Stripe, which is a pretty crazy accomplishment on its own Rnd then you 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 you did a lot of things differently.

So we're going to talk a lot about how 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 you'd found true Product Market Fit? Anurag Goel : 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 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. 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 the first instance of OK, I think we're really onto something here. Pablo Srugo : Let me dive deeper on that.

I would agree that what you're saying is a necessary condition for Product Market Fit. The question to you is, when do you know that it's sufficient? 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 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 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 were feeling? Anurag Goel : I think people have to love it enough to tell other people about it. So you have to have this viral word of mouth grow.

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 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 : 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 it was, 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? Anurag Goel : 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 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, OK, well, 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 differentiator product 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 for.

Pablo Srugo : Based on many of the founders that I've interviewed on this show, I've got a bit of a theory and frankly, from some of the founders that have told me themselves. 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?

Where does a developer see the value? How do they see the value? Anurag Goel : 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.

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 : What was the before and after?

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 what were people used to relative to what you offered? Anurag Goel : Oh, I think people were really used to having to configure a bunch of things.

Yeah, 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. Things like private networking built in, things like HTTP 3, 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.

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 : 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 it's 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, 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 minutes, is it that quick, or was it that quick? Anurag Goel : Yeah, 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 : That makes sense, and 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 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 referral bonus points or whatever, generally speaking. You're just doing it because you want to be the first to know, you want to tell your friends, you want to help.

Whatever it is, but it isn't 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 or you tell about this product, they're going to be wowed quickly. If you know they're going to have to onboard for three weeks or two weeks or even four hours, You're, yeah, maybe I was, try this thing, but it's gonna be a bit of work.

You know, you don't wanna be the guy that, whereas if hey, you're gonna do this thing and right away you're gonna see value. You might tell ten people, guys, you have to try this thing and, 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. Dropbox maybe, but rarely, right?

It's gonna come from getting somebody to that wow woman quick, that they organically just want to do it. They want to tell their friends because the social cost is low. Anurag Goel : Yeah, however, there are counter examples where time to value is actually really high. But word of mouth was awesome and, 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 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 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 : Very counterintuitive, yes, that's true. For every startup rule, there's a lot of exceptions to it. So now let's go, now that we know kind of where that moment was, where you felt things were working. We'd love to go through the story a little bit, especially the before.

Why do you decide to start a company? And what was kind of the original, the idea? What's the origin story here? Anurag Goel : So having been that early at Stripe, and I stayed there for almost five years.

I was at a point in my career where, 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 : 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. 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 at the space that you looked at and so on. Anurag Goel : Yeah, so one of the ways in which I started exploring these domains was, OK, well, what are the big problems out there right now?

And what can I do to help, right? It has to be the intersection of my talents and skills, and interests, and what the problem means to be solved. And 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 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. OK, 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?

In the best case, many decades but in the worst case, at least a few years. 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 : 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, smooth up into the ride. 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 difference between making it really big and actually just failing might be closer than you think. It's a pretty crazy world inside there. Anurag Goel : 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 domain that was big enough, ambitious enough. Because if it's not big or ambitious, then you don't have to spend a lot of time on it, right? You build it and 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 or the next several decades. Everyone who uses Render will have every new feature we add, right? It's something that we keep building and 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, I looked at healthcare for a while. Learned everything that I could about healthcare and then realized that I was not going to solve healthcare through technology and I wasn't really the kind of person who was happy to have 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 continue to build great products, and win on the basis of that. Healthcare is not that.

Pablo Srugo : I also think, by the way, just to pause on that. I think 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 tech might address this stuff on 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. Anurag Goel : 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 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 : This was just as part of the course? You did it for the classmates sort of thing? Or you did this as a product?

Anurag Goel : I started building it for them, but I built it as an independent product. Pablo Srugo : Got it. Anurag Goel : It actually took off. Again, through word of mouth, because it was so easy to use.

I quickly got to like ten thousand data scientists on the platform. Pablo Srugo : Wow. Anurag Goel : 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, 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 : Was that more personal or was that more market size driven? The decision to focus on application versus data science? Anurag Goel : 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 : Yeah, it's gone pretty big. Anurag Goel : Exactly, so again, 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 OK, 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. So the application engineers don't have to worry about infrastructure.

Pablo Srugo : I'm really worried because listen, you've been listening for what, ten, twenty, thirty 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. So take your phone out and hit that follow button.

I have a big question on this because some of these problems, however you get to them. Maybe not obvious, but then a problem like this. I'm just trying to pull my way back to 2019, right? And you come to me and you say, I've got this idea and I want to make application developers go to production with one click.

It's kind of one of these ideas where you hear it, you're like, well, yeah, of course. If you could do that, 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?

Why wouldn't they have invested in making this process as smooth as possible? Anurag Goel : 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 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.

It's not an organizational imperative and they always have these low level products, right? And so even when they build a 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 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 : It's a great answer and I think a very true answer. And for some reason, an answer that oftentimes, unless it comes from you know, a proven exited founder, then it's whatever. But a lot of times, 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, and the answer is just because they could they a hundred percent could, you know, a lot of times oh it's gonna take them long. They could obviously do it, they just won't.

Because 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 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 this small team with a limited budget, with the 50th best PM on it at AWS, and that is that's actually doable.

Anurag Goel : Absolutely, so yeah, so we're not trying to build out massive data centers and spend $80 billion on buying more GPUs, and megawatts of electricity. That's not who we are, we can't do that. 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. Pablo Srugo : So now we've got kind of the idea and how that came about. Walk me through launching the product and 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, idea to MVP to really launching, what was that like?

Anurag Goel : 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. Pablo Srugo : Did you raise once you had the idea, or did you raise later? How did you structure that side?

Anurag Goel : No, I raised after I had a working version and then I went and hired our first engineer who's still at the company. And then, we built out a team of total four people and we said, OK, this is it. This is the 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 under featured 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 : And how did you do that? Was it besides tech? You went TechCrunch's route, 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? Anurag Goel : 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 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 : Yeah, talk to me about that because this is really, really important at a certain point. If you've already got an app and it's already in production, the value is maybe not as clear.

You have to find, there's a point in time where it's holy shit, I really need this and then you do the work, and you got it. And you're yeah, OK, I guess. How did you work that? That's not that simple.

Anurag Goel : No, I just, like, look, this is the future. You're using an antiquated product and this is going to be better for you. Pablo Srugo : Like, hand to hand combat? You would just convince them you should just switch.

Anurag Goel : Yeah. Pablo Srugo : Is that where the credibility comes in? Like that's, you had a relationship, they had credibility, they're like, OK. Anurag Goel : 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 think developers often want to use new things. And that always plays to our favor, or it did back then. I wish we had more users early on, but 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, looking back, if I were them, I would think twice knowing everything I knew about at Render. But the Pete Buttigieg campaign ran all of their infrastructure on Render in, 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 : Let's go deep on that.

Because if I understand correctly, you got a $10 million ARR with no marketing spend and no freemium. You literally you had a free trial and then you have to, 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 ARR, because you know not spending on marketing and not having freemium. That's a very unique place to be in.

Anurag Goel : 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 : How long from zero to $10 million ARR? How long did that take? Anurag Goel : Oh, it took a while. We reached $10 million around maybe the end of 2021, or the beginning of 2022.

Pablo Srugo : And you launched 2019. So, two to three years? Anurag Goel : Three years, yeah, from the founding of the company. Certainly almost four years to get to $10 million ARR and VCs wouldn't fund a company like that these days.

Pablo Srugo : But these days, everything's cute. You can't compare it to these days. In normal days, even in those days, from launch to $10 million in three years, I think it was. Because, we used to talk about you hit a million, then you triple, triple, double, double.

That's kind of gone, but you're more or less on that path. Anurag Goel : 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 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 : But 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. you could spend into it, but you always have this trade off of do I focus on spending, getting more people, more awareness. Whether it's PR, paid mark, whatever it is, there's always a way to drive, spend it 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, it seems you focused a lot on the latter and I assume that was by design strategy but maybe tell me more about the thinking there. Anurag Goel : 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?

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. Pablo Srugo : It's another point 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. You might offer a service that could be profitable, but it's not profitable and actually, the faster you grow, the more you burn, right?

You remember, PayPal early days or like, 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 have to make that shift, but it's this dance, it's this dance.

Cause 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 got to, you got to play with that as you go. Anurag Goel : 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 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 : I was going to ask about team size. You're four people when you launch, so you're very lean. When you hit $10 million ARR, end of '21, early '22.

More or less, how many people were you? Anurag Goel : We were probably twenty five, thirty people, something like that. Pablo Srugo : And then the other thing I want to talk on, because it's something else that you did differently. Which is you've got a lot of users.

Today you have, I think, six million developers, is that right? Anurag Goel : Yeah, more than six million folks on the platform. Pablo Srugo : You know, back then, you had less. But you probably had tens of thousands, hundreds of thousands of developers and you, for a long time, had no support organization.

You didn't have really customer success or support. You had your engineers kind of fulfill this function. Tell me more about how you structured that, why you did that. Anurag Goel : 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 are 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 made a lot of people long term happy users of Vendor.

And we kept doing it until it felt like we just had too many users who needed to talk to someone. Pablo Srugo : When was that, more or less? At how many employees or ARR did you start really hiring a support team? Anurag Goel : I think we must have been around, yeah, twenty five or thirty people.

Pablo Srugo : OK, around $10 million ARR, wow. Anurag Goel : Something like that and then we hired some support folks who, this was like right after our series A. 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 ten people. Pablo Srugo : How did you structure that? Tell me that road to $10 million and your engineers are the ones doing support. How did you set that up to make it work?

Anurag Goel : It was a rotation. So in the beginning, we were thinking about maybe daily rotations but then we quickly realized that the context switch is just so disruptive. That it would be better to have an engineer do support for an entire week and then do 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 : There's 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 the regular meetings that you have on product roadmap? How did this exposure, because every engineer would have rotated through this, and then you have these discussions about, OK, should we build this?

Should we build that? How do you feel like that kind of fed into those meetings? Anurag Goel : Yeah, it really helped, 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, we 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 : Yeah, I have to imagine, especially for a product like growth type product. The product is your growth engine.

It's always important, having great products is always important but frankly, depending on your sales motion, how you go to market, who is the user, the buyer, all these different things. It can matter more or less. But when you're doing product like growth, you're not even spending on marketing, your product is the growth engine. It's the only thing that matters and so I just think about when I used to have those kind of product roadmap type discussions internally.

And even when I look at the companies I work with. The CEO, the salesperson, they've got this edge and the salesperson is often not even in those meetings. So it's but, the CEO in the early, early days is almost the only bridge, and you're hearing the engineers and what they want to do and the designers, what they want to do, 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 first hand opinion, right? Of reality, how much better those discussions are and, the outcome of that should really show up in the product. Not just what features build, how you build them, everything about it. Anurag Goel : Absolutely, yeah, and it did.

And even after we hired support engineers, we don't have level one support where folks are not technical. We only hired people who were able to understand coding and were able to 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've seen customers go through different versions of the problem and so they could actually sometimes come suggest a solution that would serve multiple people at the same time.

So again, it came down to 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. Pablo Srugo : And then maybe the last question, because you're a pre-gen AI company that is still doing really well, kind of post-gen AI. There's three buckets. There's the ones that are clearly, I've got a portfolio company that they were always using AI, and then when AI got better, they just exploded.

It took them up. It was a crazy way for them. There's other classic V2V SaaS companies, like the SaaSpocalypse, that are clearly suffering and there's some that have no impact. Where AI just didn't really change fundamentally their business.

What camp would you say you're in and then how have you kind of adapted to this AI world. If at all, if it's even been a big change for you? Anurag Goel : Oh yeah, it's been massive for us. 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 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 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 what we do, and who rely on us to keep their applications, and 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 the latest version of Claude Code and Codex.

Pablo Srugo : Oh yeah, when you can walk your dog and talk to Claude Code. And have it build stuff for you, it's going to build a lot more stuff. Anurag Goel : Yeah, and so our revenue has just changed. It's 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 observe each step, and you can have a parent task and a bunch of child tasks.

So we built that product. It's going to be in GA by the time this goes live. 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 right now.

Pablo Srugo : Perfect, well, let's stop there. Let me ask the last question we always end on. What would be your number one piece of advice for an early stage founder that's just in that early phase of finding Product Market Fit? Anurag Goel : 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.

Pablo Srugo : Perfect, thanks so much, man. Really appreciate it. Anurag Goel : Of course, thank you. Thank you for having me, this is great.

Pablo Srugo : So picture this, it's months from now, years from now and one of your founder friends. A 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 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.