Rendering the Future of the Cloud with Anurag Goel, Founder and CEO at Render

(Intro Narrator at 00:00:00) Today, we're talking to Anurag Goel, founder and CEO at Render, about the ways in which they're unlocking the true potential of the cloud. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:17) One thing I didn't know that I was curious about, but I didn't know when we talked last, is that you were one of the original employees at Stripe.

(Anurag Goel at 00:00:26) That's pretty cool. Yeah, I was the eighth employee at Stripe.

(Joel Beasley at 00:00:32) How did that opportunity come about?

(Anurag Goel at 00:00:35) Oh, as so often happens with companies of that size, entirely by chance. So I started using Stripe when it was still just a handful of customers. Most of them were just friends of the founders. I signed up to get notified when they were accepting more invitations, and I probably got invited in the first wave in December 2010. And that's when I actually—I think it was fall 2010. That's when I integrated it. It was called /dev/payments back then. Terrible name. The founders thought it was really smart, but in the end, sanity prevailed and they changed the name in March 2011, but they didn't tell any of their customers, including me.

(Anurag Goel at 00:01:23) And suddenly, all my payments API requests started getting redirected to this new domain called stripe.com. And I was like, what the hell is going on? I reached out to them. They're like, oh, yeah, this is the issue. And then I started giving them a lot of product feedback, and the product was not amazing back then. We hadn't launched yet. Stripe hadn't launched yet. And they were still figuring out how to make it entirely PCI compliant, but also the API experience was very different from what was actually launched.

(Anurag Goel at 00:01:56) And so through that feedback back and forth, I got to know Patrick, the co-CEO. And I was in—I used to live in Sunnyvale back then, and they were in Palo Alto. So he invited me over. We chatted some more. I was mostly just giving them feedback, and I liked the vibe, but I was working on a side project. I had a full-time job. But then in July 2011, Patrick reached out to me and asked if I'd be interested in joining. I said no. Well, actually, I think that was earlier in the summer. Anyway, earlier in the summer of 2011, Patrick asked me if I'd be interested in joining. I said no. But later, because I was working from home and my wife was going to go to grad school in the East Coast, I decided that I was going to go insane if I kept working from home. And I did not want to look for another job. The Stripe opportunity was kind of there. I enjoyed the team I met. It was only four people. And that's how I ended up there. I started working there in July 2011, and then Stripe launched in September 2011 on Hacker News.

(Joel Beasley at 00:03:02) That's amazing. Yeah, I found them probably shortly after their launch when I was just looking for better APIs for payments. And then I just told my clients at the time—I was doing a lot of freelance work—I said, we're using Stripe because I have toolkits for it. It's integrated. I was into Rails at the time. I was like, I got all the screens. I can just drop it into the project, and payments aren't a big deal.

(Anurag Goel at 00:03:23) Yeah.

(Joel Beasley at 00:03:24) And so that's pretty cool. When did you—did you leave Stripe and then found Render?

(Anurag Goel at 00:03:31) So I left Stripe in February 2016 when it was about 450 people. Obviously, the valuation was around $5 billion, and the company was doing really well. I'd been there for almost five years at that point, and I decided that I was in a position to be able to solve a different problem, one that appealed to me a little bit more than payments and fintech. And because of my Stripe experience and because Stripe did so well, I was in a position where I could really spend time on figuring out what that next thing was. And it was almost like a responsibility for me—or I took it upon myself as a responsibility—to figure out how big of a problem I could truly solve in terms of making a positive impact in the world that I also enjoyed working on for the rest of my career.

(Anurag Goel at 00:04:32) And so I was looking for something really ambitious, looking for something that benefited a lot of people in a very meaningful way. And so my way of figuring out whether I was interested in a given domain was to go build applications in it. And even just one application in a domain and putting it in production to try and get a sense of whether I would love the idea for decades as opposed to just the initial rush of an idea. You buy a domain and you're like, all right, this is going to be my next startup. And then three weeks later, you're like, well, you know, it's fine. And so I wanted to spend enough time in every domain I was looking at to figure out if there was founder-market fit. And what I realized as part of doing this was just putting things in production was so broken. And so in fact, before I started Render, I started a tiny one-person company, which is actually interestingly relevant again these days, although the company no longer exists. It was the first service or one of the first services to offer data scientists a one-click Jupyter notebook in the cloud that was backed by a GPU so they could run deep learning model training and experiments.

(Anurag Goel at 00:05:51) And this was, you know, end of 2015—sorry. This was end of 2016, early 2017 when I built this because I was taking an online course. I wanted to learn more about deep learning. And I saw all the data scientists there really struggling for weeks trying to get a Jupyter notebook up and running on an Amazon instance with a GPU. Obviously, Amazon did not make it easy. They just gave you an instance with a GPU attached, and you had to go install all the NVIDIA CUDA libraries, and you had to make sure that the versions were just right. And then you had to figure out how to connect your Jupyter notebook or Jupyter instance running on that platform in a way that was secure. And so I built all of that just because it felt like an interesting problem to solve. But again, as part of building that bigger project, we eventually got acquired by a smaller company—or by another company—called doc.ai. And it got acquired because by then, I had already started focusing on Render, and I didn't want to work on this other thing anymore. And I didn't want to work on it because I realized that data science—I don't identify as much with data scientists as I identify with developers. I'm an engineer myself. I'm a developer myself. And so as part of building these apps, I realized that the complexity of putting anything in production was still incredibly high, especially if you were doing something even slightly more advanced.

(Anurag Goel at 00:07:16) So, you know, you can spin up a website, a static front end easily. And even back then, Netlify was around and Vercel was around for the front end. But there was really nothing that approached the whole problem end-to-end in a way that was built for modern applications or in a way that allowed people to get the benefits of these new cloud technologies, like Kubernetes, like containers, without having to learn all of that themselves, without having to spend months on trying to find a DevOps engineer, and then more months trying to set up this infrastructure on AWS. So my goal from the beginning was, and still remains, to create a new paradigm for how cloud applications work and how they're operated and managed and make that operate at a much higher level than what the current set of cloud providers, the hyperscalers, provide. And the hyperscalers like AWS and Azure and GCP, they're very good at providing these small primitives. And it's possible to build really amazing services on top, but it's very complex. It's very error prone. It's very tedious. It requires lots and lots of just human effort that could much better be utilized building products and moving a business forward as opposed to on DevOps. And that's really Render's mission, which is to change how people develop, deploy, scale applications in the cloud to make them much, much, much more productive and help them move much faster.

(Joel Beasley at 00:08:45) So how are people doing this currently?

(Anurag Goel at 00:08:48) There are a lot of options, obviously. It's a large market. That's the other thing. And this was one of my criteria as well. I wanted to solve a large problem. And, you know, by some estimates, there are about 100 million developers in the world. And something like this affects every developer who's trying to put anything online or anything in production or even before their portfolio project or as a hobby project. And back in 2005, 2007, Heroku forged a new path, and they were actually really great for their time where they allowed people, especially folks building Ruby on Rails apps, to get something up and running really quickly with sort of this 12-factor app methodology, which was really great for the time because everyone else was struggling with, you know, how to put a PHP server online on a shared VPS. And clearly Heroku did quite well. But they were acquired by Salesforce in 2010—and maybe it was 2011 or '12, but Salesforce gave them a lot of resources early on, so that allowed them to grow and continue to grow.

(Anurag Goel at 00:09:57) But around 2015 or so, they started being starved of resources and platform development more or less stagnated. And so Heroku wasn't really innovating for modern applications. And that's why when I built my applications, I knew that I couldn't even build them on Heroku. This Jupyter notebook thing that I talked about, there's no possible way to build that on Heroku. And the goal for me was to think about all the advances that have happened in technology since 2005, and figure out what a rethinking of a cloud application platform would look like if you consider the new technologies that we have at our disposal, and if you completely get rid of all the baggage that Heroku has had from the beginning with their sort of outdated stack. You know, they've had a lot of trouble even just adding HTTP/2 to their stack. And that just bogs them down. And especially with Salesforce now, there's just a lack of innovation there that I think has become synonymous with Heroku these days. And so we see a lot of customers moving over to us from Heroku. But interestingly, a lot of people—in fact, more people—move over to Render from AWS than from Heroku.

(Anurag Goel at 00:11:11) And they move over from Google Cloud and Azure and AWS because they need the features that these hyperscalers can provide if you build everything on top. But they really don't want to or can't spend time or money hiring DevOps engineers and building these features. They really want to focus on their business. And, you know, everyone really wants to make sure that they move fast, they give their customers what they need, that they spend as little money on salaries and equity doing that. And we're seeing that the complexity of the clouds continues to increase. So when I started Render, I think AWS had maybe less than 100 services. Now it has nearly 300, and you have to continue to find ways to glue all of those things together to build a solid production, scalable, self-healing application that is secure. And Render just does that for you. Render runs as an entirely independent cloud. And behind the scenes we use multiple cloud providers, but that is not visible to the user. It doesn't need to be. Ultimately, they only interact with Render. And it all starts from a single GitHub push or a Git commit, and Render makes sure that from that point onwards, your changes go to production in a way that is incredibly safe, reliable, fast, and that we make sure that you stay up and stay scaling and that your customers get what you want from the cloud.

(Joel Beasley at 00:12:38) That's pretty cool. Does it automatically scale up?

(Anurag Goel at 00:12:40) It does. Yeah. It has auto-scaling built in. It has APIs that you could hook into to plug in your own scaling strategies if you really wanted to. And the goal for Render has always been not just to make it easy to get started, but also to continue to support applications as they scale in complexity. And again, it's relatively straightforward these days to build a platform that makes it easy for people to get started because you can just copy what a bunch of other people are doing, right? Including companies like Render, and a lot of people have copied us. What's more interesting is making sure that as companies grow and as their application architectures become more complex and built of more and more moving parts, that the platform can continue to give you the degrees of freedom that your complexity needs. And so those degrees of freedom could be your ability to run an entirely private set of services that can only talk to each other and nothing outside, say, a production environment. It could be allowing IP address control for your Postgres instances or just making your Postgres instances completely private. It could be being able to store data on a volume, which, you know, 12-factor Heroku thinks is anathema. But there are applications that need to do that. And so I think there's a lot of—as the cloud has become more and more pervasive, there are a lot of ways to build applications. And Render wants to support you in any way we can to help you build your application the way you want to.

(Anurag Goel at 00:14:23) So we're not prescribing a specific way of building an application. We are the furthest you can be from a 12-factor app. Now, if you want to do 12-factor app, we have all the things that you want to do that—

(Joel Beasley at 00:14:34) I haven't heard this. I always interrupt people when they're using things I haven't heard yet. This is the first time I've heard of 12-factor app. Can you tell me what that is?

(Anurag Goel at 00:14:42) Yeah. So back in the day, Heroku propagated this methodology of building applications which consists of the 12 commandments, if you will, of how to build cloud applications. Yeah, it's—and I think that it was probably useful for the time. Again, we're talking about 2007, 2010. And now it's, you know, we're 15-plus years on from that time, and 12-factor apps can only do so much. This is why people end up graduating from Heroku to AWS. But the concept of 12-factor has nothing to say about what if I need my application to store data on a disk. What if I need my application to only be available through a private network. What if I need to provide people a certain way of restricting access to certain team members and not to others. So I think it's just a simplification, but it was great for its time because it was battling what the existing paradigm was, which was, you know, people would spin up stuff on a VPS and there'd be all kinds of foot guns, or they would just use an online shared PHP host. So if you wanted to learn more about this, although it's completely outdated at this point, it's at 12factor.net. And I can't believe I'm actually educating your listeners about 12-factor. Do not focus on building your application strictly to 12-factor standards. Build your application the way you think is best for you, and Render will support you.

(Joel Beasley at 00:16:15) Yeah. That's actually one of the things that has been most interesting about me hosting this show is people write in and tell me stories all the time. And how they misuse advice is always fascinating to me. My favorite one—brief story—is the two-pizza teams. Jeff Bezos or somebody came up with this two-pizza team thing. And so the person reached out to me, like, I thought if I just got this—just got the teams to the right size, just to the—I was like, whoa. I was like, you have to understand the value you bring to the marketplace, how a team needs to be structured in order to deliver that value in the most optimal way, and that's going to look different for an agency, then it's going to look for a Fortune 1000, then it's going to look for a startup. It's going to be vastly different. But you've got to design your engineering teams to produce the product and serve the market, you know?

(Anurag Goel at 00:17:05) Exactly. And so, hopefully, that was good advice for them.

(Anurag Goel at 00:17:08) Oh, yeah. I think the technology industry is always looking for shortcuts, just like, you know, as humans, our brains are wired to spend the least amount of energy we can on a given problem to get to an end goal. And that was great when we were in the deserts of Africa trying to outrun lions and stuff.

(Anurag Goel at 00:17:31) But I think it's very different now. And we need to make sure, as humans, we've evolved to understand the root cause of an issue. We can, if we spend enough time thinking through problems, truly figure out whether a piece of advice applies or not. And I think most people overall can get sucked into this sort of herd mentality or hero or cult worship, more or less. And you saw an example of that earlier this weekend, the Labor Day weekend, when everyone's talking about founder mode.

(Joel Beasley at 00:18:12) I saw that running around on X. Paul Graham or somebody put some article out about founder mode. I didn't read it because I was just a little bit exhausted of founder content because it gets targeted to me so much. But I did see a number of people repost it, and they had strong opinions on it. Can you give me the TLDR?

(Anurag Goel at 00:18:32) I think the essay itself is a TLDR. It's not very long, and there isn't a ton of real examples or substantive content that you can take away from it, except for the fact that the fundamental idea of the essay is that founders should not be shy of getting involved in the details of their company. And if the advice that they're given is, "Well, just hire execs and let them do their job, and you should never interact with anyone other than executives who report directly to you," and that's the general advice that a lot of people get as companies scale. And the point of the essay, the point Paul Graham is making as well, is that is not how a lot of the successful companies we know operate.

(Anurag Goel at 00:19:23) And he uses Airbnb's example, and having that passion for the problem, making sure that you can approach even the smallest problems in the company with the mentality that a founder brings to the table. Now, you can be in founder mode even if you're not the founder, right? You can have this global optimization function instead of just being very narrowly focused on your job and making sure that you get promoted, making sure that you keep your job as an executive. Now, we have at Render, we have so many people who operate in what Paul Graham, I think, calls founder mode.

(Anurag Goel at 00:20:01) It's not very specified, so this is also a bit of a Rorschach test. People are kind of reading what they want into founder mode, which is just, you know, going back to what I was saying earlier, there's this prevalence of cultish following for certain ideas and concepts that allow people to maybe use them as shortcuts, but they don't always apply. And I think it's the same thing for AWS today. "Oh, I should just use AWS and I should use Kubernetes." And guess what? No. You shouldn't have to use Kubernetes to get the features that you want. And that's really what Render is bringing to the table. It's coming back to bringing you all the way back to what you're talking about.

(Anurag Goel at 00:20:41) I think the goal for Render has always been, well, if you want features like auto-scaling, self-healing applications, really fast builds and deploys, instant rollbacks, different kinds of deploy strategies, you can get all of that from a modern platform like Render without having to go build all of that yourself today.

(Joel Beasley at 00:21:04) Can you describe to me—I mean, I understand the general concept. I think a lot of people listening, they understand when they hear self-healing. Like, okay, I understand the concept. Yes. But can you give me an actual example of when an application needs to self-heal and how that works?

(Anurag Goel at 00:21:22) Yeah. So anytime your application hangs, right, it stops responding. And I know we've all seen that every once in a while, you know, your web server will suddenly stop responding to requests. As is often the case with technology, you turn it off and you turn it back on, and it seems to work, right? And so we can apply the same concept to servers, and we do, but instead of manually having to do that, the platform knows when a server is hung because it is constantly pinging it. Render's constantly pinging the server for responsiveness. And if it gets stuck, then Render automatically restarts your application as the most immediate method because, you know, it can't go wrong if this is a stateless server. It's not responding. Let's just restart it. And, you know, five times out of ten, that will just solve the problem, and you won't have to worry about it.

(Anurag Goel at 00:22:18) And you don't even kind of see it except for the notification that we send you saying, "Hey, we restarted this application." And we allow people to specify health check paths, so Render constantly pings those health check paths on their web server. Or if it's just a private TCP application, then we continue to check it for reachability. And if we cannot reach it for whatever reason, or if we get an HTTP error code also, then in those cases, you can configure it to restart the application.

(Joel Beasley at 00:22:49) Oh, that's pretty cool.

(Anurag Goel at 00:22:51) Yeah. And this is the basic sort of modern feature that companies need but have to build themselves on things like Kubernetes. And, you know, even Heroku, for example, had never thought about health check paths. You had to go in and figure out if your application's stuck, what you should do. And that's not how the world works anymore. The world is completely different. Applications are more complex than ever, and they need these modes of healing themselves.

(Joel Beasley at 00:23:20) And they show you a white screen that says there's an error, check your logs.

(Anurag Goel at 00:23:24) Yeah, yeah, exactly. Yeah. No, I mean, yes, sure, you can check your logs. But you know what'd be better? If you don't have to do anything at all.

(Joel Beasley at 00:23:31) Yeah. That would be much better. Did you VC this or bootstrap it? And where is that at growth-wise?

(Anurag Goel at 00:23:39) Yeah. So I think something as big as this is hard to bootstrap because there's a lot that we need to build from the ground up, right? Because otherwise, we would be no better than what exists out there, but also what you could build yourself. And so our goal has always been to build so much more than you can ever build yourself that you'll never want to move away from Render, and that is what we see now.

(Anurag Goel at 00:24:05) So in terms of growth and, obviously, going back to venture capital, we have raised around $80 million in venture funding. And our goal remains to become self-sufficient as soon as we can. And a lot of that will come down to continuing to spread the word about Render. And our growth has been entirely organic so far. We don't really have a marketing or sales team.

(Anurag Goel at 00:24:33) And we still, despite all that, we have 1.5 million developers on platform, and we're signing up nearly 100,000 developers every month. And that is all entirely word of mouth because people love the platform. Developers love to talk to each other about the platform, and then they see that they can grow their applications. So even our revenue continues to grow, has grown quite a bit, despite what people are seeing outside of AI. Render continues to grow its revenue entirely organically. And the next stage for the business is going to be all about making sure that more people know about what we're doing here so they don't have to deal with AWS.

(Joel Beasley at 00:25:16) Very cool. So you got some VC funding before day one, or did you build a prototype?

(Anurag Goel at 00:25:22) Oh, I had to build something. I mean, going back to what I was saying earlier, right? I could have gotten VC funding earlier, but it didn't make sense to me because I need to make sure that I felt really good about what it was I was doing. And I had users, real users, before I went and formed a whole company.

(Anurag Goel at 00:25:43) And obviously, I spun up Render, the early prototype, in, I think it was the winter break, 2017, 2018, and got my first user website on it, showed it to my friends. They all loved it. They were like, "Yes, this is exactly what I want." And after people started using it more and more, just within weeks, I kind of knew that there was something real here. And then I wanted to find someone to work with, and I found someone, but I didn't have cash to pay them. So that's when I went and raised some money so I could hire them. We could really get started on building everything for production.

(Joel Beasley at 00:26:22) We talked a lot about the product, I guess, from a developer perspective. From a CTO perspective or VP of Engineering, how does it—and a lot of people, it's very clear for me if they're starting a new project, right? New project, easily start a new service. But there's a lot of people listening that are on Heroku, that have applications that are running on Heroku. How does it make their lives easier from an executive standpoint?

(Anurag Goel at 00:26:52) Yeah. Great question. I think the biggest thing that differentiates us is you can continue to grow your application the way you wanted to without getting tied down by Heroku's limitations. So just as a really simple example, if your application needs more than 14 gigs of RAM, Heroku does not have that plan. You can't do it. Or if you need your Postgres database on Heroku to not be open to the public internet, that's a problem. And so we see a lot of people coming to us from Heroku, and these are larger customers of Heroku. And even though we aren't building Render necessarily to replace Heroku, we see a lot of people coming to us because the fundamental idea of Render is the same, which is you shouldn't have to worry about the cloud. Now, we also see people, once they move to us, their applications tend to perform better, while their costs go down, and they still obviously don't have to hire any DevOps engineers.

(Joel Beasley at 00:27:51) Well, what more could you ask for? Your costs are going to go down. You're going to have more freedom. That sounds like a smart move. We actually use Render here at our company.

(Anurag Goel at 00:28:03) Oh, wow.

(Joel Beasley at 00:28:03) We actually built a large language model and trained it on, I think, a couple hundred episodes of the podcast. And then we put it up on Render. But I talked to my engineers, they said they had a good experience, and it's always worked when I needed it to work. So I've got nothing but good things to say about you guys.

(Anurag Goel at 00:28:23) That's really great to hear. Would love more feedback, maybe after the episode, on what we could have done better or what we can continue to build for your team.

(Joel Beasley at 00:28:33) Absolutely. Now, who isn't Render for?

(Anurag Goel at 00:28:37) Great question. So if you're building an infrastructure company yourself, so for example, if you're building a database company, you are probably not going to want to use Render because your own financial gross margin, business margin profile depends on how much you spend on the cloud. And you actually do have to get people who are comfortable dealing with the nitty-gritty, the primitives, that the large cloud providers give you because you have to tune things at a lower level, which is what Render does too. You might want to use a specific kernel. You might want to tweak a certain OS-level setting.

(Anurag Goel at 00:29:21) So I think when you're doing things like that, you're typically a company that is building infrastructure itself and selling infrastructure as a service, pretty much like Render. So you shouldn't build that on Render because I think you'll need the kinds of things that we could expose, but we don't because we're not building for you. We're building for the people who really want to just move fast and work on their product as opposed to their infrastructure.

(Joel Beasley at 00:29:50) Very cool.

(Anurag Goel at 00:29:51) But when your product is your infrastructure, that changes.

(Joel Beasley at 00:29:54) Do you have any cool stories of teams using Render?

(Anurag Goel at 00:29:59) Yeah. You know, we've always had stories from the very beginning. In 2019, the Pete Buttigieg campaign, back in the day when he was running for president, for the Democratic nomination, they ended up using Render. And they moved to us from Google's managed Kubernetes service because it was way too complex, and they were having a lot of trouble dealing with it. And they'd hired these two people who, again, going back to what I said about fashion-driven or cult-driven development, they were like, "Yes, we have to use Kubernetes." So they built out the system in Kubernetes, and they weren't very good, so they had to part ways with them. And so now everyone's like, "Well, what the hell do we do with this? We don't really want to learn Kubernetes." So they moved to us from Kubernetes, and the most interesting part about that was they tested our platform scaling limits five years ago in ways that we had never anticipated.

(Anurag Goel at 00:30:56) So every time Pete was on stage for the presidential primary debate, every time he finished with his closing statement at the end of the debate, there was a massive spike to his website and the infrastructure. The teams were just not able to keep up. In the very beginning, I think we're talking about mid-2019, maybe, even Render's platform was tested in all kinds of ways, and we weren't able to keep up the first maybe one or two times. But then we figured it out. We worked closely with their team, and then we were actually able to make sure that they were up throughout the rest of the debate season, which I thought was really cool. And I remember all of us, we were a tiny team. We were like four people then. So I really appreciated the trust that they put in our team. And we were glued to our laptops as the debates were happening and just making sure that all the graphs were—

(Joel Beasley at 00:31:52) The only time developers get political.

(Anurag Goel at 00:31:57) Right? Yeah. We had to know exactly when Pete was going to give his closing statement. And we had to make sure we were monitoring all the graphs. Another really cool story is actually something that happened over the course of, at this point, you know, five-plus years. This tiny startup, just three people, the founders, they started using Render for their primary cloud provider back in 2019, and they continued to grow. Their startup became successful. And as they continued to grow, they continued to expand the boundaries of their own application complexity, and they started demanding more and more of what Render could do. And we've been able to keep up with their demands and actually stay a couple of steps ahead of them.

(Anurag Goel at 00:32:45) And now there are hundreds of people, and they're built entirely on Render. And they're spending a lot of money on us, over $1 million a year. And the goal for them is to continue to expand on Render instead of—you know, a lot of people think at some point I have to go hire a team of DevOps engineers and move to AWS. That's not the case. So this is the most obvious example I can give you of, like, look. You don't have to do that. You can continue to grow on the platform even with hundreds of people in your company and, you know, hundreds of engineers too, because Render supports that and will continue to support that. And Render is becoming, as we continue to build more features for larger customers, it becomes even harder and harder for people to think about building all of that stuff in-house. And so it just becomes a really productive platform for people to grow their companies on. And, you know, I hope that within the next maybe two to three years, we'll have our first public company hosted entirely on Render.

(Joel Beasley at 00:33:43) One of my favorite questions to ask, you know, developers or engineering leaders is to tell me about a tool that made your life easier because a lot of people won't have answers.

(Anurag Goel at 00:33:52) Oh.

(Joel Beasley at 00:33:53) But some of the best developers have surrounded themselves with things intentionally to make their lives easier. There are people that learned it in college, and they've just been doing it the same way since. I mean, especially you're out in California, and we both talk to a lot of tech people. So we're definitely in a chamber that is more modern, advanced tech people.

(Joel Beasley at 00:34:18) But don't forget, there's still really old school programmers punching their time cards and just writing their basic code every day.

(Anurag Goel at 00:34:28) Yeah.

(Joel Beasley at 00:34:28) And we love them too.

(Anurag Goel at 00:34:31) We do. And the thing is, I don't think that everyone has to use the latest and greatest way of building an application. Ultimately, it's about if you're a business, it's about providing business value. It is not about the framework you use. It is not about the cloud provider you use.

(Anurag Goel at 00:34:47) And that is how we build Render. How can we help you provide business value to your customers as quickly as possible? And when you think about that problem from that lens, then it actually changes the definition of the cloud. So you can imagine today you have to with AWS or even other platforms, you have to go find a lot of different services that you glue together. And it's not just for hosting, it's for other things too.

(Anurag Goel at 00:35:12) As an example, let's say you want something like blue-green deploys or canary deploys. There is no way for you to do that with any kind of off-the-shelf thing. You have to go build that out yourself, make sure that, and most companies don't do it because they can't. It's too much work, but they want that feature. Similarly, if you want previews of your entire application, where it's a copy of your production environment on every pull request that your developers open, that's very hard for people to do.

(Anurag Goel at 00:35:42) And so that's the kind of thing that Render enables. It's much more than just hosting your application. It's making it clear that you can do much more with the cloud and helping you get that out of the cloud where your entire team moves much faster from development to staging to production and onwards. So going back to the tool, was that a question for me?

(Joel Beasley at 00:36:03) Oh, yeah. Yeah. Yeah. I am curious to know what's one of the tools other than Render that have made your life a lot better.

(Anurag Goel at 00:36:11) There are so many across the board from, you know, the keyboard and the mouse that I use, the monitor I use, but also to how I use a to-do list or use a meeting transcription app. And these days, I think, actually, this might be interesting. So there are tons of these, but there's a new AI-driven note-taking app called Granola. And they don't have a referral program, but I hope that my feature requests are prioritized. But they allow you to essentially take raw notes, very raw notes of any meeting, and then they'll analyze the transcript and enhance your notes and fill up the entire thing.

(Anurag Goel at 00:37:07) Instead of just creating a summary from just the audio transcript, it's actually based around what you write as you're taking notes for a given meeting. So if you are the kind of person who wants to take some notes to make sure that you capture the most important bits of a meeting, but you don't want to continue to type during the meeting, then it's a nice way. And I'm sure there are other apps like that, but I found that Granola actually works better than some of the other ones I've tried.

(Joel Beasley at 00:37:34) Nice. Nice. So how many people are at Render now?

(Anurag Goel at 00:37:39) I think our goal is to build an organization that is incredibly efficient and make sure that, you know, we're no longer in the 2010s or even early 2020s where venture capital was just being thrown around. And I think people have realized that business fundamentals need to be solid no matter how capitalized you are. And we've all seen examples of companies hiring really quickly and then having to lay people off. And so we're being very careful about hiring. And my goal, and the company's goal is always to make sure that we maintain the best talent density in the industry.

(Anurag Goel at 00:38:22) And by that, I mean, we're not really looking to fill seats ASAP. We want to continue to increase the number of talented people at Render because great people want to work with other great people. And it's always hard to find the best people. By the way, if you're listening to this, we're hiring. Render.com/careers. I have to make the plug, but it's always hard to find the people who are both really good at what they do, are passionate about what they're doing, and are available because, you know, most good people aren't actually looking. They're happy because they're doing well in their jobs. And so our size or hiring velocity isn't limited by our capital or anything else. It's really limited by our need to keep talent density high.

(Joel Beasley at 00:39:12) Yeah. That's a smart move because you're exactly right. Smart people want to work with other people. So if you can get that critical mass of high-quality talent. Do you incentivize the developers at all to share about Render?

(Anurag Goel at 00:39:24) No. There's no referral program. And I think the biggest incentive is that Render is one of the few companies out there, maybe less than five or even, that allow you to get an application, a production-ready application up and running without using a credit card, without really committing to anything. And the reason that has always been important to me is anytime you're working with a newer provider, there are so many questions. And the first thing you want to do is figure out if this thing even works.

(Anurag Goel at 00:39:54) And our goal has always been to show people how easy it is to get up and running on Render. And so there are certain cases where, you know, we make sure that if you want to do X, Y, or Z, then yes, we do need a credit card. But you should be able to get an application up and running with a database, with a Redis app, without committing to the platform. And so I think that's one of the biggest things that draws people to Render because they see that they can spin up a ton of hobby projects that they don't use often. And so our free tier is actually built for projects like that, where you can just spin something up and you don't use it often. So we actually spin it down when it's not being used, but it spins back up when you get your request so that it's something that I think a lot of people liked about Heroku back in the day. But Heroku killed it and our—

(Joel Beasley at 00:40:45) Oh, they did?

(Anurag Goel at 00:40:47) Yeah. They killed it in 2022. And I think that was another sort of one of those nails in the coffin type things where, you know, Salesforce is now all about squeezing more out of what they already have versus figuring out how they can be more innovative with Heroku.

(Joel Beasley at 00:41:05) But I think it's a smart strategy because there are two market segments I find interesting that this works well with. One is hobby projects. Senior engineers, mid-level engineers, they're at work, but they put together, follow a tutorial, want to test something out, and they throw it up as a hobby project. But two, you've got the next generation, which is where I think your long-term win is with this strategy. You've got the 16-year-olds who don't even have debit or credit cards yet, right? Who want to, who are learning how to program. I mean, I was learning how to program at 12. Right? So the only services that were available to me were cracked services or free services.

(Anurag Goel at 00:41:44) I know.

(Joel Beasley at 00:41:45) You know? And it's a 12-year-old. You know?

(Joel Beasley at 00:41:48) You don't have anything. It's a smart move, and I think that move will serve you guys super well long term. And obviously, it's showing you in the data. It's already working well.

(Anurag Goel at 00:41:59) Yeah. And our goal isn't, you know, to give things away for free in a way that is not sustainable for the business. And we want to make sure that our free tier works not just for our customers, but also for the business. And so we've been very careful about the limits. But the goal has always been you should be able to get the power, a taste of the power of the platform, without having—

(Joel Beasley at 00:42:19) You should get it deployed. You should get it deployed. Yeah. You get it deployed. Access the application.

(Anurag Goel at 00:42:23) Yeah. You can get a subdomain on Render for your free app. And, you know, you can actually host tons of apps as long as not all of them are running simultaneously for free. So you get seven hundred fifty hours of compute time for a free application. And so you can have, say, 10 applications across the board.

(Anurag Goel at 00:42:47) And because we spin them down when not being used, each application can be a free app, and you still won't run out of your seven hundred fifty hours.

(Joel Beasley at 00:42:55) That's amazing. And then as I was reading around on your website—by the way, your documentation is really good.

(Anurag Goel at 00:43:01) Thank you.

(Joel Beasley at 00:43:02) So getting started, you go look, they have a quick start guide. If you have a Rails app or whatever type of app, Python application, whatever you might have, there's a quick start guide, which is actually really well written, which I read through.

(Anurag Goel at 00:43:16) Shout out to our team.

(Joel Beasley at 00:43:17) Yeah. Good job, guys. And one of the things I got through reading those docs and some other articles was that you have a really good developer-first type of culture. Is that intentional there, or did that just happen by magic?

(Anurag Goel at 00:43:32) Oh, it's intentional. It's been intentional from day one. It goes back to who I am and what I care about and also derives from my experience at Stripe. Right? Because Stripe was always, back when we were still 10 people, we were still very much, hey, we need to focus on developers. It's developer first. And despite where Stripe is right now, it is still very focused on the developer experience. And I think that has continued to serve them well. And it's the same for Render. While we have much larger customers who use Render in more complex ways, our goal is always developer first because those are the people using our product.

(Anurag Goel at 00:44:16) We're not building for CIOs necessarily. We're not building for people who sign checks. We're building for people who actually use the product. Right? And we can convince the people who sign checks because the developers can convince them. And this has been proven over and over again, especially over the last decade where developers are becoming really much more influential in the purchasing process. And so that's also how we've seen our revenue grow over the years because developers love it. And then they talk to their company about us. And so we started getting larger and larger companies on Render.

(Joel Beasley at 00:44:52) That's super cool. Is there anything that we didn't get out there to the world other than people need to go sign up render.com? Amazing domain name. Maybe tell me how you got that. How did you get render.com?

(Anurag Goel at 00:45:05) Yeah. So that's a whole story too. So when I decided that I wanted to start this company, like any self-respecting developer who's starting a new project, the first thing you do is you go buy a domain name. Right? And I knew that I wanted something that would increase people's trust in us, even when we were just two people. And even when we were just simply trying to get our first 10 applications on the platform, we wanted people to know that there's a real business behind this, a business that can actually afford the domain like render.com. And so I was looking for, I wasn't looking for a specific name. I was really looking for words that sounded somewhat positive, ideally common nouns that were where the .com was available to purchase. It had not been, it was not in use by some company that would never give it up. And so we basically just went down a list, my wife and I, and she added render to the list.

(Anurag Goel at 00:46:07) I looked at what Render's situation was, and I hired a domain broker. And it turns out it was available. And this was before I had raised money, so there was definitely a little bit of, like, hey, this is really expensive. Should I buy it? Should I not? But I decided that even if the company goes nowhere, I can resell the domain for a markup after, you know, a year or two. So I ended up almost buying it with my own money, but the funding timeline worked out. So that was one of the big purchases from our seed check. But I think that, obviously, now Render is what it is, and I'm glad that we made the purchase back then.

(Joel Beasley at 00:46:45) Nice. What else did we want to get out to the world today?

(Anurag Goel at 00:46:50) I think it goes back to what we were talking about earlier about not assuming that you have to go with the hyperscalers to build this truly large, successful company. Just because that is the way things are done now, that's not how things are gonna be done in the future. And Render is bringing that future forward because the same thing happened when people moved from data centers to the cloud. But fundamentally, the experience didn't change because AWS, which pioneered the cloud, was focused on the same people who were managing things in data centers. They were like, hey, now you guys manage things in our cloud, in our data centers, and we'll give you an API to do that. But that didn't change the fundamental abstraction of the cloud. And we continue to build on top of it, and there's a thousand providers that do one tiny little thing in the cloud, and they're all trying to make money. And it's a huge mishmash because of how AWS evolved its products and its platforms. And I think Render is saying, no, that is not the ideal way. So make sure that you do your own thinking and you look at other customers. And, you know, when you search for Render reviews online, you'll find that they're uniformly positive, incredibly amazing when people find out how easy it is, but also all the things that it can do and the time that it saves them, the money that it saves them. So please do your own research. And behind the scenes, of course, we use multiple commodity cloud providers. But fundamentally, Render is building the way new cloud applications should run and how I'm pretty sure in 10 years, every application will run in the cloud.

(Joel Beasley at 00:48:46) People can sign up at render.com. I still love the name. It's a great name.

(Anurag Goel at 00:48:51) Thank you.

(Joel Beasley at 00:48:51) Thank you so much for doing this. We made a podcast. How do you feel?

(Anurag Goel at 00:48:55) I feel great.

(Joel Beasley at 00:48:56) Thank you so much for listening. And if you found this episode useful, please share it with a friend or colleague who you think would get value from it. And if you have topics that you'd like to hear discussed on the podcast, either add me on LinkedIn or send me an email, [email protected]. Every time I get an email or LinkedIn message, it absolutely makes my day and inspires me to keep going.