Why CTOs Are Ditching AWS for Simpler Solutions with Anurag Goel, Founder of Render

(Intro Narrator at 00:00:00) Today, we're talking to Anurag Goel, founder of Render, about how they capitalized on market conditions to have one of their biggest growth periods ever and more. You're listening to Joel Beasley, Modern CTO.

(Joel Beasley at 00:00:19) It's weird how time goes by so fast, but it also makes for a great conversation because it's like, what has been going on the past year since we've talked? Is Render growing? How's it doing?

(Anurag Goel at 00:00:31) Yeah. When did we last speak? Do you remember?

(Joel Beasley at 00:00:34) I think it was about a year ago.

(Anurag Goel at 00:00:36) Yeah. Well, since then, things have really picked up because we've grown our user base really fast. We raised $80 million of new funding. We brought on new folks. It's been a really exciting year, and it's shaping up to be even more exciting over the next year or so as we've launched some really cool products on the cloud infrastructure side that just haven't existed and solve the kinds of problems that we see people running into now that they perhaps weren't as aware of when they weren't building with LLMs.

(Joel Beasley at 00:01:19) Oh, what type of problems?

(Anurag Goel at 00:01:22) So the biggest thing that we've seen with anyone trying to build with LLMs is the difference in how the API calls work compared to, you know, previously, if you called the Stripe API, it returned in a guaranteed amount of time. It was pretty quick. You just had a request response model. And now with LLMs and people needing to talk to LLMs in your app, you know, these calls are long running. LLMs take a while to respond.

(Anurag Goel at 00:01:59) The streaming responses versus a one-off request response model. They're also not that reliable as a standard model. I mean, even when you talk to Claude or ChatGPT, you often see, oh, request network error or something. And it's the same thing when you call out to Claude or ChatGPT APIs. They're a lot less reliable than the previous wave of SaaS APIs that we used to work with, that we still work with.

(Anurag Goel at 00:02:30) But this is a completely different way of interacting with these APIs. And to work with these APIs, you have to build a bunch of information. You have to create a lot of context. Then you have to build a series of steps in a sequence to work with the results of these LLM calls. And we're seeing the need for people to run a lot of different kinds of asynchronous processing, which is essentially really the cornerstone of how people are interacting with AI.

(Anurag Goel at 00:03:07) Everything happens asynchronously in the background, and then there's a real-time component. And because of that, the way people did asynchronous processing in the past no longer works. The last twenty years have involved this very specific pattern that has been used for async processing, which is you create some sort of queue, and you create a worker or several workers that read off of the queue. And when you have these very long-running tasks that can fail and tasks that need to be executed in sequence, when some of these tasks need to fan out to hundreds of instances at the same time, then this model just is too simplistic. And so you require cloud infrastructure that can manage all of the workflow for you, including the tasks that need to run in sequence, including retrying the tasks that fail because they fail all the time, making sure that there's a right level of compute for each task, and that things don't get bottlenecked by a single task taking too long.

(Anurag Goel at 00:04:24) So you need to build concurrent workflows, distributed workflows, with this new way of building with LLM APIs. And we're working on a product that solves exactly that problem. And every time we talk to a customer who is working with LLM APIs or even just standard background tasks, we describe the product and their eyes light up and they start nodding. And it's going to be really exciting for us to launch this product, and we're getting close to the alpha.

(Joel Beasley at 00:05:01) Is it all under wraps now? Or do you have thought leaders within your company that are writing about this, how they're solving these problems?

(Anurag Goel at 00:05:07) It's all under wraps for now.

(Joel Beasley at 00:05:08) Okay. Cool.

(Anurag Goel at 00:05:09) Yeah. So, I mean, I'm happy to talk about it. I've talked about it publicly before because this is a very real problem that a lot of people are running into. But yeah, I mean, the SDK and how we're solving these problems internally and what we're running and all that technology, we'll start talking about it more once it's closer to general availability.

(Joel Beasley at 00:05:32) That makes sense. Because my first thought was, you know, maybe Reddit or Reddit user groups. There's other technologies out there where there's people that are running against this problem. And whenever I see this, it's like electricity. It gets created in all the different countries at different times with, you know, people.

(Joel Beasley at 00:05:50) And so I'm always looking at, like, okay. If they're experiencing it, they've identified it. You guys are processing 100 billion requests. Was that a month or a year or something? It's crazy number.

(Anurag Goel at 00:05:59) Yeah. Yeah.

(Joel Beasley at 00:06:00) Yeah. You're seeing this at a massive scale. So you obviously, yeah, you know that what you're building is going to be useful because you can see the problems happening, which is great.

(Anurag Goel at 00:06:10) Yeah. We have so many customers who are so excited about this. They can't wait, and we're really trying to get it out as soon as possible. And then there's other products like that that are emerging to solve the problems that AI-first companies are running into today. You know, obviously, working with LLMs, working with the agents, working with WebSockets, that, you know, a lot of providers in the past haven't supported WebSockets because the standard response model has been request response.

(Anurag Goel at 00:06:45) And so something like Vercel doesn't support WebSockets out of the box or at all. And that's a big problem. And so the serverless models of execution are no longer sufficient to work with things like agents that require really long-running compute primitives.

(Joel Beasley at 00:07:04) Let's talk about the AWS migrants.

(Anurag Goel at 00:07:08) Oh, yeah.

(Joel Beasley at 00:07:08) That's what we'll call them. People are coming over from AWS, from all of these different services like Heroku. They're coming over to Render. Why are they coming over?

(Anurag Goel at 00:07:20) The biggest reason is that they get more functionality for less complexity. And it varies depending on whether they're coming from AWS or Heroku. But if they're coming from AWS, then they've realized that what they're trying to do with their application, with their cloud infrastructure, can be handled completely by Render with minimal configuration setup expertise on the cloud on their end. And Render takes care of a lot of things that they would also need to build on top of AWS. For example, if you wanted to create a preview instance of your application every time you push a PR out.

(Anurag Goel at 00:08:18) So you push a pull request. You want to test it live because, you know, you can obviously review the pull request, but it would be much better if you could test it automatically and manually in a way that is very similar to your production setup. And Render just has that feature built in. If you're on AWS, you have to go build that out yourself. And so most companies don't even build it because it's so hard to build and to maintain.

(Anurag Goel at 00:08:45) And having that feature on Render is just one example of how you get so much more functionality out of the box that you would have to configure on AWS. And then if they're coming from Heroku, it's all about getting modern functionality like private networking, like persistent disks, like HTTP/3, and there's a lot of other things I could get into. But getting all these modern features that new applications, that modern applications need without having to manage the complexity of a hyperscaler like AWS. And so they see that Render is moving faster. It's innovating faster than Heroku.

(Anurag Goel at 00:09:38) It is also more reliable, based on recent events. And so we're seeing more and more people realize, well, why am I paying Salesforce all this money to be on this outdated version of the platform when I can switch to Render, get no additional complexity, in fact, and get a lot more functionality, and my costs will scale better? So as I grow, my costs don't go from n to 10 times n. They scale more linearly with my growth.

(Joel Beasley at 00:10:16) Which they should. I always found that to be crazy, how fast they scale. You just hit this certain usage tier, and then there's this premium you pay for, I don't know, the enterprise premium, I guess, is what we call it.

(Anurag Goel at 00:10:30) Exactly. And with Render, a lot of the functionality is just available self-serve because the key insight for us is, look, developers often just never want to talk to salespeople.

(Joel Beasley at 00:10:46) Amen.

(Anurag Goel at 00:10:47) Yeah. I am also one of those people. I really want to just build everything myself, and I want to test the platform myself. And especially when I'm getting started, I really don't want to talk to anyone. I just want to look at the docs.

(Anurag Goel at 00:11:01) The platform should be intuitive. And that's really what's caused Render to grow so much despite Heroku or AWS sort of being much more popular in the past, and certainly AWS remains as popular as ever. But Render's website now gets much more traffic than Heroku's website.

(Joel Beasley at 00:11:23) Oh, it does.

(Anurag Goel at 00:11:24) Yeah. Yeah. It's actually, I think Heroku's maybe at half our traffic. But if you look at, if you believe SimilarWeb results, I don't know.

(Joel Beasley at 00:11:32) They're kind of the tech stack standard.

(Anurag Goel at 00:11:34) Yeah. They're the standard. Right? Yeah.

(Joel Beasley at 00:11:35) So if you look at—

(Anurag Goel at 00:11:36) Yeah, if you look at heroku.com versus render.com, yeah, Render exceeded Heroku's traffic for the last several months, maybe even longer. I don't pay for the premium package that lets me go back three years, but when you look at the last six months. Anyway, and so I think people are really realizing that if, especially if you're starting a new application, you don't want to deal with cloud complexity. You want to be on a platform that can really scale with you as you grow, both cost-wise but also functionality-wise, then Render's truly the best choice, especially when it comes to reliability, the long-term viability of the platform. We've now raised $150 million, more than that, and we've really built a platform that has scaled to millions of developers.

(Anurag Goel at 00:12:24) We have 3 million developers on the platform now, and we continue to add a really, really large number every month.

(Joel Beasley at 00:12:32) Have you gotten into language translation, or is it mostly English?

(Anurag Goel at 00:12:36) It's mostly English still. Yeah. And the bulk of our user base is certainly in English-speaking countries. There is maybe an interesting phenomenon for us where we're apparently popular in Japan.

(Joel Beasley at 00:13:00) Well, they're efficient, and you guys are efficient. So that's a culture match.

(Anurag Goel at 00:13:04) I suppose so. Yes. And we don't have a Tokyo region yet, but as we think about new regions, I think Tokyo is one of our top next regions. London, Tokyo, Sydney come to mind. But with Japan, generally, people, obviously, the good thing about what we do is we build for developers.

(Anurag Goel at 00:13:28) Developers write code in English. Mostly. Yeah. Mostly. Right?

(Anurag Goel at 00:13:34) Yeah. And so they're used to, I mean, a lot of developers sort of pick up the English that's necessary to work with applications. And so we haven't faced so far a massive need to translate. But I do think our documentation, eventually, we will translate to other languages for sure.

(Joel Beasley at 00:13:55) Yeah. And people, you know, when they're operating in different languages, they've got their own tools anyways. So they've got their translators that sit on top of everything that they use across all their products because I've got, yeah, I've got a lot of friends around the world from the show, from doing the show. And what you said is what I have found to be true is, like, if you were to take the entire population of almost any country and then you segment out the developer software engineers, the probability of them knowing English is significantly higher than the general population.

(Anurag Goel at 00:14:26) Absolutely. Yes. Yeah. I think that's just the nature of software development. It might change in the future, but that's where we are today.

(Joel Beasley at 00:14:33) Absolutely. So when this big outage happened in June, did you guys see a spike in your sign-ups or anything like that?

(Anurag Goel at 00:14:40) Yeah. We saw a big spike in especially larger companies reaching out to us, larger companies that were Heroku users reaching out to us. And we continue to see more and more companies continue to reach out because it wasn't even about the outage. It was about the response to the outage. And, look, every cloud provider has outages.

(Anurag Goel at 00:15:06) That's just the reality. AWS has outages, GCP, Cloudflare, Azure, and Heroku. And Render's also had its outages in the past. The main thing when it comes to outages is to be incredibly responsive to customers as you fix things. And what happened with the June 10 outage for Heroku was it just wasn't clear what was going on.

(Anurag Goel at 00:15:38) Even the status page for Heroku was broken. So, yeah, status.heroku.com just didn't work, and I don't know why they didn't—

(Joel Beasley at 00:15:50) Separate for a reason. Yeah. It's separate for a reason.

(Anurag Goel at 00:15:54) Exactly. Yeah. I don't love hosting Render's status page on statuspage.io. I think it's not a great product. But having said that, the separation's the reason we hosted there.

(Anurag Goel at 00:16:11) And so a lot of people managed to—it was also related to some sort of Salesforce outage, and that's the other issue with Heroku, the heavy reliance on Salesforce. And, you know, when you log in, there's a whole Salesforce login dance that you have to do.

(Joel Beasley at 00:16:30) That's right.

(Anurag Goel at 00:16:31) Yeah. So I think people were just really frustrated by a couple of things. One, it was the length of the outage.

(Anurag Goel at 00:16:43) I think we saw the outage go on and impact people for like 10 plus hours. And not being able to get real information, not seeing that the status page doesn't work, not knowing what's going on. That's the thing that is so important to get right, especially as a cloud provider where you're hosting people's businesses. You're responsible for their livelihoods. And making sure for Render, you know, making sure that we create a public-facing incident with enough information as soon as we determine that this is an incident that is impacting our customers, that is the first step in our incident response process.

(Anurag Goel at 00:17:36) And we built a really strong culture of incident response that I'm very proud of. And that has led to the kind of reliability we see for our platform, which is much higher than any of the other modern platforms and, obviously, certainly now, Heroku.

(Joel Beasley at 00:18:01) How did you build a good culture of incident response?

(Anurag Goel at 00:18:05) The biggest thing is to prioritize it, making sure that you put reliability at the top. And when we think about allocating our limited engineering resources on new features, reliability, on something else, it doesn't matter what else we do. If we're not reliable, then everything else is for naught. Our customers don't care what features we add if their applications aren't up or not behaving as they expect them to. Right?

(Anurag Goel at 00:18:38) And so knowing that and appropriately investing in that at the exact level so everyone at the company knows that this is the key thing that we need to focus on. And so when you look back to the early days of Render, one of our engineering leaders, or the person who led the team, they were responsible for managing the AWS infrastructure at Stripe before they joined Render. And Stripe had built an incredibly strong incident response process as well. And, you know, I was there from the very beginning, and I remember how back in the day, if we saw some API requests that failed, we actually identified every single customer who was impacted, and we sent them an email with a list of API requests that failed so they could retry them. And this was a very personalized email.

(Anurag Goel at 00:19:36) And it just sort of went from there because, again, with Stripe, it's critical. If the Stripe API is down, you're not getting paid, which is, again, critical to your business. And so a lot of the early culture at Render came from how seriously we took incident response at Stripe. And then also, certainly, as we grew, we found that doing retros regularly, quickly, making sure that we actually allocate the engineering bandwidth that is necessary to work on the mitigations for any given incident to make sure that if we find that x, y, and z were the contributors to an incident, that we fix those things right away. And that might mean we go slower on building new functionality, but that's okay. That's a trade-off that you have to make.

(Anurag Goel at 00:20:41) And being okay with that trade-off is critical. So I think that it's a very cultural thing, and you have to keep reinforcing it as a CTO, as a CEO saying, look, it doesn't matter what you do, this is paramount. And then really walking the talk.

(Anurag Goel at 00:21:02) Right? Making sure that you're okay with long-term reliability work, and you're not building new features. You're not getting new revenue from this. But it makes sense for us because a lot of our customers start on Render when they're small, and they grow with us. And that is the biggest driver of our revenue growth, the growth of existing customers.

(Anurag Goel at 00:21:29) It's the same as AWS or any other cloud provider. You start small. As you get bigger, you spend more on the cloud because your applications become more complex. You create more services. Your databases get bigger.

(Anurag Goel at 00:21:43) But you don't do that if your cloud provider is unreliable. You go pick another provider that is reliable and migrate over. And that's what we saw with the Heroku outage. Right? Just like Heroku, customers are now thinking about Render, and some of them have moved, or a lot of them have moved, actually.

(Anurag Goel at 00:22:02) Similarly, if Render were to be unreliable, this growth in existing customers, the revenue from existing customers, would just die. Right? And so in many ways, reliability for us, doing that work doesn't lead to revenue that you can point to to say, oh, we did this work, therefore, our revenue went up. No.

(Anurag Goel at 00:22:25) But fundamentally it's the foundation of revenue growth.

(Joel Beasley at 00:22:30) Yeah. I've definitely seen people over-index on new shiny objects, and including myself. I've done it.

(Anurag Goel at 00:22:36) That's human nature.

(Joel Beasley at 00:22:38) Yeah. Yeah. And what I found with long-term success is that the perspective of, okay, what's my foundation and just keep reinforcing it. So I always go back to sales and product. How do I make my sales process better? How do I communicate the sale and the value better? And how do I make the actual product better? And every time I have free time where I'm not selling or delivering or something, I go, alright, fill my calendar with making the product better, making the sales process better. And I've been doing that for seven years, and it's worked.

(Anurag Goel at 00:23:10) There's a compounding effect.

(Joel Beasley at 00:23:12) Mhmm.

(Anurag Goel at 00:23:13) The more you invest, the bigger your lead compared to competitors.

(Anurag Goel at 00:23:20) And the more you scale, the more bottlenecks you run into. The better you are at fixing those bottlenecks if you invest in that. You just keep building this foundational lead and being able to scale with your customers, which I think has positioned Render as really the cloud of choice for new applications and has driven, has led to, you know, the revenue growth we've seen, the growth in users that we continue to see. And, obviously, that's what investors saw as well when they invested $80 million in our most recent round.

(Joel Beasley at 00:24:00) Yeah. Which is amazing. I mean, that's really hard to get that much money raised. It's a lot of work. So congratulations on that.

(Anurag Goel at 00:24:08) Thank you.

(Joel Beasley at 00:24:09) Question about complexity, though. Are there people, like, you know your customer pretty well. Are there people that prefer the complexity of AWS? Or, like, how do you see, and there has to be some nerds out there that are like, I know because my dad's one of them. That's how I know this personality type. So how do you address that personality type or do you not? You just focus on the people who want the simplicity.

(Anurag Goel at 00:24:36) Yeah. I think that's a great question. And I do think there has been a shift in this perspective over the years, which has also led to Render's growth. I think in the past, because you needed to build everything yourself on either bare metal and then eventually on AWS, the attitudes were, look, this is how it's done. And the people who were responsible for these things had grown up on managing infrastructure and managing it at all kinds of levels. And then eventually, ultimately, built this reinforcing belief with them where, look, I need those controls. Because if I don't have them, then my application is not gonna be reliable. Generationally, we're seeing a big shift because many of the people who are building these new applications now are product engineers. And I care a lot more about bringing the right product to market faster because there's more competition. And because at the end of the day, your customers don't care if you're hosted on AWS or if you're hosted on Render. They care about the functionality, the reliability of your product.

(Anurag Goel at 00:26:09) And so when new builders, when product-focused builders think about that, they don't want to deal with all the configuration and complexity. They just wanna move fast. And so we focus on the people who really wanna move fast, and we don't try even to sell to people who are like, oh, I need to be able to patch my VM kernel. I think it's just a generational shift. We don't need to appeal to the people who wanna patch their VMs because we just patch everyone's VMs for them. It's not even a thing that people need to think about. And I think there's a lot of parallels here to a lot of other places in technology where, for example, you know, a lot of computer use shifted from the desktop to your phone. We spend way more time consuming and interacting with technology through our phone than on our desktops. And you get so much more control on your desktop. Right?

(Anurag Goel at 00:27:16) You have access to a terminal. You can install all kinds of applications. You can patch things. You can do so much more, whereas on your phone, everything is limited by the operating system. You can only install approved applications.

(Anurag Goel at 00:27:33) You can only do certain things with these applications. You know, starting a terminal and dealing, the screen is actually much smaller. But guess what? At the end of the day, the kinds of things people do with technology are changing, and our phones are a big part of that. And so the lack of control in terms of configuring your phone is no longer a factor. And so, again, the people who are selling iOS don't care about necessarily the developers who want to build Mac apps and who want that level of control over the hardware.

(Anurag Goel at 00:28:13) Right? And similarly for Render, you can think about how Render is much more focused on giving people the kind of control that they need to build amazing applications. And these applications themselves can be quite complex, but the underlying infrastructure doesn't need to be.

(Joel Beasley at 00:28:37) Yeah. And if you build for everyone, you build for no one. Right? You have to build for a specific persona, and it really aligns with myself. How I look at products is I want to push stuff down in the stack as much as possible and hyper focus on business value by solving someone's problem and then that generating revenue. Because if you can get that motion to happen, then you have something.

(Joel Beasley at 00:29:04) But it doesn't matter if you have the coolest tech in the world if you can't get that motion to happen. I've met people who, brilliant, brilliant people who have built these things that are just difficult to understand, but they're so complex and they're beautiful and it's amazing, but they just, it's not valuable. Right? And I—

(Anurag Goel at 00:29:26) Yeah. I think that's also just the cultural difference between the DNA at AWS versus Render's DNA. AWS DNA has always been to build for DevOps engineers, people who will take the time to understand and configure all these things. And they've tried multiple times to build products for product-focused engineers, and we all know how that's gone. And at Render, we've always focused on product builders, product-minded developers, application developers, not DevOps engineers. Although Render is also used by DevOps engineers, because once you get to a certain scale, you need someone often whose job it is to be responsible for all your infrastructure. But their job is much easier because of Render, because they don't have to think about all the other things that they would have to on AWS. For example, Render already takes care of so many security needs. So one of our largest customers, there are hundreds of people. Their chief security officer is incredibly happy with Render because it eliminates a lot of the surface area they would have to secure themselves on AWS. With Render, we just take care of it. And as a result, they can focus on other things, like application security, like supply chain security as opposed to infrastructure security.

(Joel Beasley at 00:30:59) Yeah. I mean, look, the most confusing thing I've ever experienced in my life is with AWS, the whole permission systems. I was like, you need a college-level education to understand how to configure this stuff properly. If you're working with me on an AWS project, I'm just giving you super admin and calling it a day.

(Anurag Goel at 00:31:21) We've all done that. Yeah.

(Joel Beasley at 00:31:21) We've all, like, if they're small projects, like little play things and stuff, or, you know, just startup ideas, you know, I'm not doing that in real production situations, but it is a lot. Every time I've ever run into the documentation at AWS, I'm like, I need to pay someone to figure this out. It should not be this hard to set up a bucket and, like, put data there. It's a lot.

(Anurag Goel at 00:31:44) It's a lot. And we're also seeing a big change in the industry as how people develop applications is changing because smaller teams now are able to build much more because of AI. Right? They're able to move faster. They're able to build new applications much faster.

(Anurag Goel at 00:32:06) And, again, if you've seen the recent headlines, everyone's talking about how future teams are gonna be much smaller. Future teams of software developers are gonna be much smaller because of AI coding and agentic coding. And if there's one thing that we know LLMs are really good at, it's coding. And therefore, this whole notion of spinning up a large DevOps team to manage your infrastructure just has quickly become outdated. And teams are looking for power, flexibility, the ability to move fast, and they're not getting that out of AWS because of all the DevOps and, you know, everything you have to configure on top of Kubernetes.

(Anurag Goel at 00:32:58) And so they look at Render and they see that they can get all that functionality out of Render and more, especially things that they would have to build themselves on AWS. And so they just start with Render from the get-go. And sometimes a lot of these people think that at some point, they would have to scale away from Render and move to AWS. That point just never comes because we keep building new functionality.

(Joel Beasley at 00:33:25) Smart.

(Anurag Goel at 00:33:25) Yeah. And we already have the system that has allowed companies to scale to, you know, paying us millions of dollars a year. And that's really interesting. Right? So the proof point for Render, the validation for Render is how big can a company get on Render.

(Anurag Goel at 00:33:47) And so we think really hard about scaling with our customers and continuing to build functionality that helps them scale and grow on the platform. And that has been a big push for us over the last year where we built a ton of enterprise features. And that's showing up in some of the conversations we're having with these very large companies that are on Heroku or these larger companies that are on AWS. Suddenly for them, Render's a much more viable thing because we've built all these features that larger enterprise companies require.

(Joel Beasley at 00:34:24) No, that's amazing. And I think you're exactly right. We're gonna see smaller, more focused teams with larger revenue. I actually just saw, I think, like, a week or two ago, somebody put a chart together on ratios of technology employees versus revenue. You could then go down the list. There was like 50 of them, different companies, and it's like, wow, names that you are starting to know, you see a few employees they have. It's like, this is really interesting what's happening in the marketplace. It almost makes you wonder, like, how does IBM have several hundred thousand employees? It's crazy.

(Anurag Goel at 00:35:03) Yeah. And I think companies, even the largest companies, are realizing that, and they've seen all the fat that they've accumulated over the years. And just this morning, I saw a Reuters news item about AWS layoffs. And Render's been very focused on hiring the best talent and not trying to expand our team unintentionally.

(Anurag Goel at 00:35:32) And that has resulted in one of the highest revenue per employee numbers that I've seen from companies that are our stage. And we plan to continue to focus on building efficiently with a small team. And part of that comes from just the product and sales itself, and so we haven't had to build out a large sales team. We actually have one account exec because most of our revenue comes from people just signing up, using the platform, and just paying us for their usage. They'd never have to talk to anyone.

(Anurag Goel at 00:36:19) And this is what we were talking about earlier. Developers don't want to talk to salespeople necessarily, but some people do certainly. And so our tiny sales team is focused on helping some of these larger companies migrate away, and we give them architecture guidance, and we help them through each step in the migration. And that's really what it's all about for them. But the bulk of our, the vast majority, 99% of our users, never ever talk to sales.

(Joel Beasley at 00:36:55) Yeah. Well, I'll tell you how I could be both of those customers at once. As you're talking, this is what I'm thinking about. If I'm starting a small app with my buddy, Derek, and we're gonna do it, we're not talking to anybody in sales. We're, whoever's gonna self-serve and let us deploy the quickest. If I get a government contract for, like, $10 million and they come to me and they're like, hey, we need you to do this. Every single person that I'm gonna have involved in that project, and if I'm spending significant capital with, I'm gonna need to at least have a relationship with some higher-level person at the company. And for you, I mean, I guess that's probably what happens a lot. Somebody comes in through your BDR. You see that, you know, some XYZ brand that's huge came through your business development person, and then they're gonna connect you guys, have higher-level conversations with different C-level or higher people if they're considering moving large workloads over to you and they've got some concerns and questions and stuff. Like, that's what's happening. Right?

(Anurag Goel at 00:37:50) Yeah. And we also have a really strong support engineering team. And so a lot of people are able to get their questions answered just by asking in our dashboard, saying, hey, this is what we need. But, yes, for larger accounts, it is important for folks to know who they're working with.

(Anurag Goel at 00:38:09) And so, you know, we have a lot of people whose title doesn't involve sales, but they're in that position. You know, I'm one of them.

(Joel Beasley at 00:38:19) Yeah. Well, relationships and trust, that's not gonna go away. That's a human thing.

(Anurag Goel at 00:38:24) It is.

(Joel Beasley at 00:38:25) But we can do it very efficiently. Like, for example, if I've got a handful of surface-level questions, I should be able to get them answered through chat support, whether it's a human or an AI just to know if what I wanna do is possible. You know?

(Anurag Goel at 00:38:25) Exactly.

(Anurag Goel at 00:38:39) Yeah. So again, AI has gotten very good at looking at all the docs and giving you the right answer, so you don't have to go read every single page in the docs. But we try to also make sure that our support team is able to get to your questions quickly and help you through the process. And honestly, if you need to talk to someone through a sales funnel or pipeline, then we always have that option.

(Joel Beasley at 00:39:10) Let's talk about this Agentic AI project you are working on. Tell me about that.

(Anurag Goel at 00:39:16) Yeah. So as I was saying at the top of the episode, we're seeing people change fundamentally how they're building applications because there is this expectation from end users that more applications will be smarter, have AI features, and because AI is just able to do a lot more. LLMs are able to sort through mountains of data and even with hallucinations can create enough context as a starting point for people. We're seeing that the change in application architectures requires new infrastructure primitives. And by talking to our users, many of whom are building AI native applications, we've seen this need for really accessible infrastructure for asynchronous tasks and workflows.

(Anurag Goel at 00:40:30) And there are products in the market that can give you some of that, but there's no end-to-end, from code to infrastructure solution that essentially just needs you to define your tasks and workflows very simply through annotations for your existing methods in your code and just takes care of all the execution for you. And that includes retrying tasks when they fail because a lot of AI tasks do fail. They take a long time and, you know, machines fail, network failures happen all the time. And so it's very important for resilient infrastructure to be able to work through all of these demands. And there's also now everyone's building this sequence of taking information from your database or from other places.

(Anurag Goel at 00:41:37) And then the next step is massaging it in a way that LLMs can respond to and understand and creating that context. And then sending that API call to an LLM, when you get the response back, again, massaging that response in a way that can be displayed to the user. So you can see that this is this long sequence of steps that needs a durable workflow engine because each step can fail. Each step is dependent on the step before it.

(Anurag Goel at 00:42:08) And sometimes, because of how LLMs work, you might need to scale out the same task or the same kind of task to 100 different LLM calls at the same time. You might call an LLM API with similar inputs 100 times or whatever. And let's say you're processing 500 files through an LLM. Again, you could think about that in terms of those concurrent calls that need to happen. At the same time, you don't want a long running task, which again, LLM calls can be, to clog up the rest of your pipeline of tasks that you need to perform.

(Anurag Goel at 00:42:46) And so there are a lot of these considerations that really require more modern infrastructure primitives compared to what used to exist, which was this queue that workers would pull things from. And you could basically just increase the number of workers to get more processing power, but you didn't really have this notion of retries or you didn't have a notion of sequencing. And you were limited by the number of workers you could run, and you still had to manage the workers at the end of the day. And a single task could clog up the whole pipeline. Like, if a worker can handle one task at a time, which is usually the case, then if you wanted 500 tasks to be executed at the same time, then you would have to scale to 500 workers.

(Anurag Goel at 00:43:41) You would have to manage that scaling yourself. But then if you have these 500 tasks, but then the next task comes up, do you create another worker? What happens then? And so there's a lot of these challenges where ultimately developers end up managing all this worker infrastructure, and it just doesn't scale with LLM-first applications. And our goal is to fix all of this and to give people a really clean workflow management engine that allows you to run your workflows and tasks durably, resiliently.

(Anurag Goel at 00:44:20) So things happen in the order that you specify. And if something fails, it gets retried automatically. And each task can have a different amount of compute because not every task needs the same amount of compute. And you can, most importantly, you can have really clear observability into what's happening in this pipeline. Because sometimes these workflows can take days depending on the amount of data you have, how many API calls, the rate limits you have, all of those things.

(Anurag Goel at 00:44:56) And you need to understand what's happening at each step of the way. And so building a system that doesn't just execute that, but also gives you very deep observability into your entire pipeline, we found is incredibly critical to building the new kinds of applications that people want to build today. So that's really what we're thinking about and what we have built. And we're close to launching it in alpha. We're working with a lot of our existing customers who are really excited about it.

(Anurag Goel at 00:45:26) And I think that it'll be a pretty big game changer for how people run asynchronous tasks and workflows.

(Joel Beasley at 00:45:36) That's awesome. And yeah, everybody wants detailed information about what's going on in a long running process because I was very excited when Grok and GPT and all those started showing the thinking, like, chain of thought.

(Anurag Goel at 00:45:50) Exactly.

(Joel Beasley at 00:45:51) Because I was like, that is so much better. You know, it just bothers me even when I'm dropping a video file that's like 10 gigs just to sit there and just watch. Like, I want it to tell me more now. It's like, tell me more than just that.

(Anurag Goel at 00:46:05) Yeah. Yeah. You know, we all love progress bars, and we all make fun of the Windows progress bars that went from like 5% to 2% to 90% and then back to 2%.

(Joel Beasley at 00:46:20) Oh, man. On that blue screen of death. Oh, goodness.

(Anurag Goel at 00:46:24) I think they're changing that. It's no longer blue. I read something about that recently.

(Joel Beasley at 00:46:30) Oh, no. Well, do you know what color it is now?

(Anurag Goel at 00:46:34) I think it might be black.

(Joel Beasley at 00:46:35) Oh, it's black. Alright. Alright. We'll hold you to that. This just in.

(Joel Beasley at 00:46:41) Oh my goodness. Alright. I'm curious. I want to do just a couple leadership questions as we wrap up. Is that okay?

(Joel Beasley at 00:46:47) Because you're leading this company. It's growing. It's scaling. You're the founder. You've stuck with it for almost a decade now, which is amazing. As you've gone on this journey, I always like to ask people for a piece of leadership advice, and I'm going to give you the constraints. Something that you heard, you implemented, and it stuck with you today.

(Anurag Goel at 00:47:13) The most important thing that new leaders, new CEOs have to deal with is scaling themselves. And the best way to scale yourself is to hire people who can do everything that you want to do, ideally much better than you. So even after you hire them, it is also really important to let them run with things. And even if they don't do things the way you would do it, it's important to focus on the outcomes.

(Anurag Goel at 00:47:54) And so I think it's very hard for founders, especially, to give up control. And control in terms of how things happen at your company. Because guess what? In the beginning, you had 100% control when you started the company. Right?

(Anurag Goel at 00:48:16) How things happen was entirely up to you, and then you hired people and so on and so forth. And so I think the advice that continues to be incredibly important for any founder and leader is to build the team that can replace you and to continue to build that team at every step of the way and be very conscious about how you're spending your time. And, you know, there are times when I get involved in things that I think are really important for me to be involved in. But when I pull myself out and look at the 30,000 foot view, what's actually necessary for me to do is find and or hire or identify the right person in the company to take that on and not me. And I have to constantly remind myself as a founder who's just so used to being so involved in everything.

(Anurag Goel at 00:49:15) At this, you know, but so you have to be very strategic about how you spend your time. And I think that's really the biggest advice that continues to resonate with me and something that I think about every day. How am I spending my time? Am I doing it in a way that sets up the company for success and doesn't make me the bottleneck? Or am I becoming the bottleneck for the rest of the team?

(Joel Beasley at 00:49:39) Oh, it's good insight. Thank you. Thank you for sharing that. I want to do some work. Let's do some work. For CTOs that are considering a move away from the AWS complexity, they want a better, happier life. What's the first step?

(Anurag Goel at 00:49:55) Well, the first step is to talk to us and reach out to our website. We'll be really happy to help think through your architecture and what a migration might look like and work with you on a migration plan.

(Joel Beasley at 00:50:12) And then for people that just want to jump in and dive in and just do a weekend project with it, what's their best way to get started?

(Anurag Goel at 00:50:20) Just sign up and start doing stuff. Yeah. You have a lot of examples. You don't need examples of documentation. All you need to get started is to connect your GitHub repo, and we suggest how to build your application for Render or how to start it up, but you can change how you build it.

(Anurag Goel at 00:50:44) You know how you build your app. It's pretty much the same as building your app locally, and you know how to start your app. You know, yarn start or npm start server or whatever. And that's all you need to get started.

(Joel Beasley at 00:50:59) I love it. I love it. Render.com. We made a podcast. How do you feel?

(Anurag Goel at 00:51:05) I feel great. Thank you.

(Joel Beasley at 00:51:07) 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 would 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.