The Infra Pod - Render is defining what taste means in backend infra (Chat with Anurag from Render)

Episode Date: December 1, 2025

In this episode of The Infra Pod, hosts Tim and Ian are joined by Anurag, CEO of Render, to discuss the journey of building a modern cloud platform from scratch. The conversation covers Anurag’s background at Stripe, the challenges of cloud infrastructure, the evolution of developer tools, the importance of abstraction and taste in product design, and the future of agent-driven development. The episode is packed with insights on scaling platforms, developer experience, and the shifting landscape of cloud computing.

Welcome to the InfraPod. This is Tim from Essence and Ian, let's go. Hey, this is Ian Livingston, CEO and co-founder KeyCard, the best place to get agent access and identity. Today we're joined by NRI Goal, CEO of Render. What in the world was it, Anurag, that decided to go start a cloud platform from scratch? What was the insight? What was the pain you were feeling and what type of crazy juice are you on to say, I'm going to go start a company in the first place.

I'd love to learn. Yeah, absolutely. So I think it all comes down to what I was doing before Render and maybe not going too far back in 2011 as the 8th person to join Stripe, which was called slash devs slash payments back then. I joined shortly before launch. We launched in September.

Stripe obviously grew, did really well, continues to do incredibly well as a company. I spent the next several years just helping build the company in any way I could. And as I was doing my own thing at Stripe, which is, you know, building out our fraud systems, our risk teams, some of the infrastructure behind that, I also noticed how our infrastructure team kept on ballooning. And most of the work that they did at Stripe was just managing AWS EC2 instances. That was it. How can we make sure the instances stay up? How could to make sure we update the image on them,

how do we make sure they have the right auto scaling, how do we manage network load balancers, how do we do SSL, how do we do domain. So all of that just required ongoing effort from engineers who were really some of the best engineers in the world, but were working on things that were completely undifferentiated and often just mind numbing and error prone.

So that was that. And I don't think much of it, besides the fact that, well, this seems wasteful. And then I left Stripe in 2016. And I was at a point where, obviously, Stripe had done well. And so I was just frankly in a position where I could retire or do something else. And my wife and I spent a lot of time discussing this. And we decided that we would try to contribute in some way.

And retiring would just bore us. out of our minds and just we were too young to do all that. So anyway, so my goal then became to find a large, ambitious problem that I could work on for effectively the rest of my career until I can no longer work. And, you know, Warren Buffett decided to retire at 95. I think that's a great inspirational example. I would love to maybe best his 95 and with the miracle of modern science, maybe I will be able to. Anyway, so my goal was to find something that was large, really meaty, and was solving a big problem that I saw in the world. And I started with trying to build something in healthcare, which obviously is very broken, but I quickly realized

that what I really needed was to build and win on the basis of product and technical innovation and that's not what health care is about or at least back then it wasn't and even now I think the bigger issues with health care are much more around policy you can't really solve them with software even though some people have solved parts of it with software and it makes a lot of sense but the biggest bang for your buck comes from policy changes but then I looked at some other domains and I was just sort of just figuring all of this out over you know the next year and a half and I was building a bunch of applications myself putting them I'm online, building Kubernetes clusters myself.

I actually built and started a tiny company, which is really just me, that was the first GPU-backed, one-click jubiter notebook in the cloud. It was called Cressel. And this was when it was just incredibly hard to get an AWS GPU instance to have the right libraries, to have the right software, so you could actually get a Jupyter notebook running on it. And all these data scientists were trying to run deep learning

and were trying to do it through Jupyter notebooks. And they were running into issues. So as I was going through my own deep learning journey at the time, I was like, well, let me go figure out what this is. I found that this was like a big problem that they were running into. I was like, okay, let me get into this. So I built out a whole cluster-based solution where you could just go in, sign up,

and there's a big button saying start notebook. And behind the scenes, I would provision a GPU and you would get all the libraries and then you could just do stuff and you had a volume attached to it. And that was pretty interesting. But then I also realized that I cared a lot more about developers, product builders, as opposed to data scientists. Now, I love data scientists. We hire them at Render.

If you're a great data scientist, please apply. However, just being who I am, I cared a lot more about solving problems for the people who are building applications day to day. And that led me to essentially taking a broader view, going away from just like, hey, here's a Jupyter notebook for data scientists back by GPU, to, okay, well, I keep running into these issues with my own applications where I'm trying to put them online and have to follow the same sequence of 500 steps. and then I have to maintain these things over time, and I saw that at Stripe, and it was the same thing. So why isn't anyone fixing this? And I realized that AWS is incredibly, incredibly good at low-level primitives, but as soon as you start talking about core products for application developers,

you start faltering or they start faltering. And you really get into products that are not well thought through, products that have a lot of rough edges. And fundamentally, I think AWS doesn't have an incentive to make their high-level products better because they know that he can always kind of convince people to hire a bunch of infra engineers and go build everything on the low-level products. So this is why they never improve their, actually their versions of things that are similar to render are more or less on life support.

If that, there are probably 10 different ways to run applications. and containers on AWS, most of them are in life support, some may be active, but they all get to a point where they stop working as you scale, and then AWS can just sell you more EKS. You can just fire up a Kubernetes cluster. Why would you need to do this more complex thing on this high-level product, right? To me, it felt really important to elevate the level at which most companies were operating in the cloud. It seemed like a big problem that everyone faces.

It is a large problem. The market is massive. And I realized that I could truly have an impact here and really help builders and therefore have increasing leverage, not just doing my own thing, but really helping everyone who's building. And that's the fundamental idea behind Render, which is to help ambitious product developers ship their applications. in the cloud quickly, confidently, and at scale. And that's what led to starting the company in 2018, and now we're here in 2025. And so looking at the 2019 announcements,

almost like your press and things like that, is really about removing DevOps, right? And I think that sort of stood like the tackline. And back in 2019, that's what was fun times. You know, like the Amazon Bill S1 from Pinterest was mentioned, about how much they've been spending. At the top of the primitives, right, like Amazon gives you a low level

and you really need to be able to reduce the complexity. What we've seen a lot of people never be able to do. Like, you can argue Heroku done one of the best or better ways, but many other people, that the primitives to get rights reduced complexity has never been that great. And so a lot of companies either try to hide too much, therefore, like, I can't do anything

or, like, hide too little. And, like, you have leaky abstraction that basically becomes, like, not even like a fun product to use by most people. What do you think was really the thought process when he said, hey, I want to hack a better abstraction that doesn't really have to leak out so much complexity. What has been like the thing you thought you got rights and maybe some of the lessons you learn in early days to try to figure out what is the right even like the way

didn't think about designing abstractions? Yeah. The most important thing I'd say is to think about your end user. And when you think about it from that standpoint, then a lot of decisions become much easier. And for us, the end user has always been the application developer, although in the future, it will also become agents and is kind of becoming agents in some ways.

But back then, it was just really application developers. And that's still true. An application, putting yourself into an app developer shoes, I mean, that was easy for me and for other people, that render because we've done that, allowed us to then think about, okay, well, instead of VMs, what do I actually need to launch an application? What do I need to build an application? And then once I do that, what do I need in terms of observability? What kind of tools do I need? And the most important realization was that you have to start at a new level and then work your way

Up or down from there. And I say that because a lot of people have tried to build high-level abstractions. I think where they stumble is they stop evolving the platform to continue to work for more complex use cases, or they don't focus on it enough. And with Render, it has always been one of our topmost priorities to help the companies that are scaling the fastest on Render. And in doing that, we've actually built. entirely new ways to do things that they would have done very differently on AWS because at the

lower level of the abstraction. And that has allowed us to, again, continue to build this really interesting surface area, but all of that operates at the level of abstraction that you start out with, as opposed to saying, okay, well, we're going to then put you into a lower level of distraction just because you want to do X. And that's where I think AWS is not well incentivized or organized because they stop at a certain place and they're like, okay, well, if you want to do this, then we're not going to have this product do this for you. Fargate can't do this. You have to use EKS. And we don't have that choice. Render does not have this choice. We've explicitly said we're not going to offer managed Kubernetes to people. We could. A lot of

people would be very happy. I think we would make a better managed Kubernetes product than literally anyone in the world, given what we've done. But we're not going to do that because all we have is this top level that we're building for app developers. And if you need new features, this is where we're going to add them. And that leads to a completely different product and a completely different way of thinking, which I think render has done better than any other product in the space. Help me understand. I spent some time at Salesforce actually more than some time. And you know, enterprise CRM is like absolute massive world complexity, right? Like the reason Salesforce sucks to use is because of all the use cases and the complex

enterprise requirements and like you enter it and there's like a thousand knobs and turns. And ABS is kind of the same, right? Like they're trying to build a platform that supports, you know, the small smalls and also the biggest big. And as a result, you kind of have this like rising tide of complexity that comes. I'm kind of curious to understand like how do you think about how to build the right abstractions at render to solve that. Like what you mentioned is basically trying to solve

as a complexity crisis that comes from all of the different use cases. You're basically saying, you know what, we're just going to focus on like this band of use cases or this level of complexity. And we're not never going to go deeper because there's just a huge amount of like developers on this band. Or how are you approaching about like dealing with that complexity iceberg that comes from trying to support like massive breadth of use case

and integrations and requirements? We do that by continuing to. to evolve the product daily. I mean, there's no secret sauce. You just focus on, like, look, we have to do this. And then you have to have a sense of taste and design. But then you also have to think about progressive disclosure of complexity.

The problem with something like AWS or maybe even Salesforce is that they don't actually think about progressive disclosure. They just like put everything in your face. And then people are lost, right? AWS is menu bar has a drop down with search fields because it's too big that it's too much going on. So we want to make sure that you can still get started really easily, and we focus on that, but then as you need more things that

they're available. Now, this means that not everything is going to be visible to you when you first create a service in the dashboard, but once you've created it, you can go somewhere in the dashboard to update it, but maybe, maybe you don't even need to go into the dashboard because you're sophisticated enough to use an API. And so we'll just have you use the API to update that one setting that no one uses, but we're not going to expose it in the dashboard because 99% of the time no one needs it. And that's a decision that you make, right? Like, do people actually care about having all of this all the time in every single surface area, in every single interface that you expose? And the most obvious thing to do is to just do it

everywhere and have this rule. But we've shied away from that. And we've been conscious about where we expose things. But it also just takes time. It takes time and focus. I don't think it's impossible. It's just that companies stop focusing on it. I haven't found it to be that difficult, quite honestly, besides the fact that, look, you have to focus on it.

And you have to make sure that you pay attention to it. It's all about balance. You have to make sure that every new thing you add, you're actually, there's a central product thinking that permeates all your products and features. it's a cohesive thought process and someone is thinking about it from a high level or there are principles that you've written down and I think when you're small enough

you can just have one or two people who are reviewing everything and that works but as you get bigger then you have to build that muscle into the organization at every layer you have to hire people who think from a sense of design and have a sense of taste a lot of this does come down to taste quite frankly

and taste is something you develop over time. I mean, I think that's a really good segue. I have so many questions. But one of my core questions, like, building render, I mean, you have significant a number of services, you have a significant number of products. You have a lot of usage. You've been around a long time.

I think, like, in product design, a lot of people have asked this question. I mean, certainly we have a lot of anecdotes about people like Steve Jobs. But how do you scale taste? Like, how do you actually, as you add more services, as you think about complexity, as you think about core primitives,

do you think about the experience? Like, how do you scale that out culturally? And I think then the other question I sort of have here is how does this reflect from a technology perspective, right? Like in terms of what it means that you build over time. And I think there's the other core question I have that kind of all revolves around this other component. Like, if you think of Amazon, a lot of what they're giving people is like, well, the enterprise has standardized Kubernetes. We're just going to give you Kubernetes, right? Like, you just want Kubernetes.

You just want. And a lot of it comes from people who say that are Postgres or Redis. and they're said, okay, well, we're just going to give you, like, the Lego blocks. There's an operable and, like, we'll talk about Lock-in. Like, Render is an opinionated platform with opinionated components. How do you think about developing those opinions and how do you think about dealing with, like, the lock-in question or not that's associated? Yeah. Yeah.

So I'll answer maybe the second question first. So render is actually way less of a locked-in platform and in some ways maybe even. way less of an opinionated platform than say something like Purcell or Cloudflare workers, where you actually have to build your application to the platform specification. Render does not impose a specification on your applications. You come in, if you want to run a Docker container,

be my guest. If you want to run five Docker containers, we give you a private network. We give you volumes that you can connect to your containers, we give you service discovery out of the box. All the undifferentiated work that you would have to do, we do all of that for you. We make sure that we give you zero downtime deploys. We make sure we give you health checks.

All of that stuff is built into the platform. But we're not fundamentally telling you use our framework or use this new constraint on how you should run your app. If you can run your app as a server process, then you can run it on rendered. It's as simple as that. And you can take those Docker containers and you can go run them on Kubernetes if you want, but most people choose not to

because they get everything that they would get out of Kubernetes, everything that I just said, you know, load balancing, auto-scaling, volumes, health checks, zero downtime deploys. The reason people end up needing Kubernetes or they go towards Kubernetes, we built and fixed all of those things with those requirements into the platform.

But then we make sure that you can build in any framework, what application language, and the core abstraction there is, of course, Docker these days, which is one of the reasons I'd say render is better timed than Sayo Heroku was back in the day. So amazing. I think there's so much we can talk about this abstraction and tastes. And I actually very curious, it might be fun to even maybe talk to make a very specific example. Because I think a lot of times we learn a lot from like very specific antidotes. Do you have any specific example here where like, you know, taste was really like a guiding principle that you are like, like, it's all about Kubernetes.

Maybe they have like a specific example where like, hey, we could have done something in a very abstract way or very like leaky abstraction or like not a untasteful way and taste guidance or something. And that kind of like changed even like how to user behavior and stuff. Of course. Yeah. Yeah, absolutely. Absolutely. Yeah. I mean, here's an example.

So if you want to build out this notion of, let's say, staging environments and production environments using Kubernetes and AWS, how would you do that? Like, how would you guys actually build it today? That's a good question. So if we run Kubernetes today, like, most like you just wanted a GKE-E-KS's sort of management platforms, right? Like simpler one-click install. Right. On top of that, it's a wild west because there's so many options. That's the thing.

Okay. Yeah. But let's say you pick an option. Now you have an AWS account, and you want to have both staging and production in this account, but you do want to isolate production from staging completely. How would you do that today in AWS? I'd create another account.

You'd create another account, right? Yeah. Then you have to deal with two accounts. There is no other way to, like, really isolate production and staging. Now, we'd render the taste comes in. when we enforce that no user should have to create a second account to have that separation. So how do we do that? It's very straightforward.

I mean, this is not some magical innovation. But obviously, we allow people to have the notion of environments within render, within the same account. But then to isolate things, when taste comes in, really what we want to say is, you should be able to just click a button and say, this is isolated from all other environments. in my account or in my project. And this environment, no one can connect to it from outside, including my own users, including my own staging or development environments. And that's literally just a toggle in render.

So while you can have production talk to your development or staging or some common resources, development and staging, if you configure that one toggle in your production environment, development and staging will never be able to talk to production. And in AWS, you would imagine if you tried to do it in the same account, you would have to set up security groups, IAM rules. You would have to configure every single service, maybe with some sort of tag, and then you would have to have a network policy that you associate with it.

There's tons of configuration that goes into that, but it renders literally a toggle thing. And that's because we understand that that is a thing that developers, application developers, and teams need to do. So really understanding your user and then making those bits really easy, that's how I think render has really been able to differentiate from, say, the AWSs of the world, who are not going out and saying, oh, hey, all these application development teams, tell me how you configure staging and production.

They're just saying, hey, guess what, just create a new account. Everyone creates a new account. We're just going to be fine with that. And we're saying, no, we're not going to be fine with that. So I think that's just a simple. example of how we think about what users and especially developers and developing teams should be able to do things and how I think the rest of the world, or especially hyperscaders, think about it.

And can you tell us a make example where maybe you got it wrong initially? Like the tastes you figure out, maybe the assumption here was make it extraction and didn't actually pan out and ways you learned from that and fix it. Yeah. So what renders Postgres, we have a fully managed Postgres. And in the past, I think we aired on the side of look, developers just really want Postgres to be, they wanted to just work. And we had some conversations and internal debates about how much we should expose to people on what's going on in Postgres behind the scenes. And our earlier Postgres version, just didn't have as much observability in terms of logs, in terms of being able to manually fiddle with certain configs. Over time, we've realized that that is the wrong attitude, that I think developers want more control of their Postgres.

And so now we're actually building out a whole custom configuration system for Postgres. But even there, it's not like you can just go change. anything you want or shoot yourself in the foot we've actually gone and taken the time to look at literally every potential setting in postgres and we've exposed most of them but we've definitely had some level of debate around certain settings saying like does this even make sense to the end user to the application developer and so we've gone from being a little bit of a postgres black box to opening it up and then opening it up further and I think that will continue in that direction. But a lot of that has come from customer feedback. And you can go

too much in the other direction. But the good thing is, well, customers are customers. They love us and they tell us what they need from us. And you have to keep listening to them and fixing things as you find them. So yeah, that's maybe one place where I would have been more open from the start. This is a really good transition. And we have to talk about the big monkey in the room or elephant or whatever people say, you know, with the rise of things like MCP, the rise of coding agents like Kircher. Yeah.

How are you thinking about, you know, both render as a platform offering, but also your own thoughts. And how do you think this changes the way that developers consume and build applications and how is that changing where you think about render itself and what you build and how you service them?

Yeah. So I can tell you how it's changing already. The primary thing that has changed over the last, maybe 12 months, maybe 18 months is development teams are able to move a lot faster in some cases, in a lot of cases. And they're also able, developers are also able to develop entirely new applications and stand them up faster because, hey, Cloud code. And there's a huge zero to one process that Cloud and other AI agents have been able to help humans with because just like for a lot of things, just getting started is the most tough part.

And when you ask a coding agent to say, give me a prototype to do this, it gets you started. And then you can go from there. So many more ideas are being developed as a result of AI coding. And that has led to an explosion, a massive explosion in the number of applications being put online. This is something we've observed. Render signups and the applications being host on Render have completed. exploded over the last 12 plus months and this has less to do with render we were

still building out our marketing team but it is a lot more to do with the state of the industry the other big piece is how more and more companies and startups and developers are building applications that use LLMs that offer LLM functionality to users and are building agents. And of course, the two of you are no stranger to this. I think agents are just, there are many, many, many more companies that are developing agents. Having said that, I think that we're still in the super, super, super early innings of how many companies are even thinking about agents or thinking about developing agents.

And we know that people are still finding new ways to use LLMs in their products, which means that exponentially larger number of businesses will find use cases for agents within their products. And with Render, we've seen that, you know, increasingly and very quickly, starting from our largest users all the way to the very long tail, there's been a proliferation in companies that are building with agents on Render. And I think that's partly because Render's platform is incredibly well-suited to long-running applications, which is essentially what agents are.

It's incredibly well-suited to, you know, to WebSockets, which is incredibly hard to impossible to do on platforms like Versailles. It's really well suited to horizontal lot of scaling. It's really well suited to large machines that need to process a lot of data. And so we've seen a lot of people migrate over to us from, you know, they might have started on Versal and they've found all these limitations around Vercels, sort of what they call their back in infrastructure, but really it's still front-endy infrastructure.

And we're hearing from them that they need Render to build new capabilities for the agents that they're building. And this is partly why we've decided, and I think Render is the only cloud platform doing this right now, but others I'm sure will follow. We've decided to build workflows as a native capability into Render, workflow orchestration, durable workflow orchestration as a native capability within RETA. So if you go to render.com slash workflows, it's ready, it's available in Alpha. We're slowly getting people in, and the response to that has just been insane. And it's not just for agents and LLM apps.

A lot of people are using it for just standard backend compute. I think it's how everyone is going to run async tasks going forward. People are going to stop running background workers, and I'm happy to get deep into this. But this old way of doing async task, which is running back, background workers and managing cues and then running lots of different kinds of workers and trying to figure out which worker has how much memory and CPU and which worker is operating on the most critical tasks and which workers are blocked and which tasks are failing. All of that work is completely unnecessary for application teams to do, but they're doing

it today. And that's what render workflows is solving. But that's just our first product in the suite of products we're launching over the next several months to help with people who are building agents and LLM apps. Actually, yeah, didn't you realize there's render workflows? It's super cool that I'm looking at the documentation and stuff like that. One thing I also notice is to render MCP server. Can you talk more about what is MCP super for and how would you even think of your infra products offering?

Where does this sit as well? Yeah, so to me, an MCP is just honestly another interface. It's not massively additive beyond that. And we launched it and we've publicized it and we've seen tons of usage. And most of that usage, I'll say, is for debugging with LLMs. So you see an error in your app. You ask in your MCP, you can say, hey, help me fix this error. And because the MCP is hooked up to Cloud and it's hooked up to render's

tools, which is essentially our API and API endpoints, it can give you a much better interface to debugging and it can also do stuff. So like it can update your settings to fix a bug in your configuration. So I think people are using MCPs to speed up their workflow and to allow LLMs to aid in the debugging workflow for render. And there are a few other use cases, but I'd say the debugging use case remains the primary one that is not available necessarily in our dashboard. You can imagine, though, that Render will have an AI agent in the dashboard that does effectively what the MCP server is being used for for debugging. And I like to say that MCP servers in some ways are today's way of capturing user demand for

new features that you should build with LLMs, because all they're doing is, giving an LLM access to your API and then users are saying, okay, well, hey, LLM, help me do this. Well, why do you need an MCP server for that? Why can't you just build it into your product and build it into your CLI? So we'll see that happen. It's quite possible that MCP servers are kind of a transitional technology. We'll see what happens.

But I do think that it's not a given that MCP's servers are going to be around three years from now. And as you think, like, agents become more agentic, right? Like today, we kind of have the equivalent of, like, rudimentary cruise control, right? Or, like, you know, we could use co-pilot. So can kind of do some stuff for us. But if we're not constantly paying attention, they'll, like, drive us off the cliff or like into the car in front of us or whatever,

how do you think the sort of like access models, how do you think the types of products we build change as, you know, over time agents start to eat more and more of our workflows, both like you can kind of see with Kircher, right? where it starts with beautiful tab completely. It was just really much better tabbing. But now we have like, it actually can go off and do like real work without my involvement.

It comes back to me. Like how are you thinking about that product evolution and how do you think about that technological evolution for render and in relation to your MCP as well? Yeah. So I'm thinking about it independent of MCPs. And I'm thinking about in terms of just tools that you make available to agents. And it's pretty clear to me that all the operations that we perform,

perform as humans today going through a software development lifecycle, about 90% of those operations will be performed by agents in the future. And just like you check in code today and you have, well, first of all, you write code that's already been taken care of by agents. You write tests, agents already doing that. You commit the code. Agents will start doing that. Maybe they're doing that in some places already. You run it through CI. I think agents are going to essentially get into your CI system and because of the proliferation and compute and because of the, you know, there's no human limit on how much code you can write and how many tests you can write. What will happen is that every step of the software development life cycle is going to

evolve to meet heavily parallel and very high throughput needs. So we'll write many more tests or will see many more tests, but that also means that your CI system will need to support way more throughput than it does today. It needs to be faster. It needs to be more parallel. I think all the CI tools today are going to break because agents are going to be writing so much more code and testing them. The same thing applies to deployment pipelines. Today, how we treat deployment pipeline like cattle, like everyone's going in and tuning things and making sure everything works and then, oh, CI is broken, let me go fix it. That's just not going to be an option.

That's just not going to be an option with agents because they're going to be generating so much code that needs to go into production. Eventually, they'll get there and eventually we'll have agents running their own canary deployers and testing and then going fully to production as they get the results back. All of that basic, simple human judgment

that we apply at every step of the software development life cycle, a lot of that will be transitioned to agents. And now that just means that every tool in the software development lifecycle will need to change accordingly. For us, for render, that means we need to make our build system massively more parallel, massively faster. We need to make our deployes much faster. We need to make every step of our entire process really just much more high throughput. And that's the direction in which I think the world is going to go and humans wait for stuff today, and it's fine and we complain about it, but agents are not going to wait. I think we're already there to go into our favorite section. I think you started from

MCP's not going to last for two years. We're basically going to get into the spicy future. All right, tell us what do you believe that most people don't believe yet in infra? Oh, I mean, this one's easy, right? believe that in the future, AWS is just the AT&T and the Verizon, and all the value and innovation is happening above where they operate. And I think we're already starting to see cracks in their armor. And there was a recent Business Insider article. Now, you know, it's Business Insider, so it is what it is. But there was a business insider article about how AWS is missing out on AI startups

and they're not going to other hyperscalers. They're actually just using Neo-clouds, and they highlighted two startups there. One of them was Base 44, which is a really popular vibe coding platform.

They didn't mention Render, but Base 44 grew up on Render, still runs on Render, and AWS missed the boat there because Render has all the capabilities and the scale and the reliability to run some as complex as Base 44 at their scale. And there's no need for Maor at Base 44 to manage AWS when rendering can give them

everything wants. And that's how things become dump pipes over time. And I don't think to me this is controversial in any way, but a lot of people still think, well, why would I use Render when AWS exists? To them, I'd say, just wait. What's your view on, I think, with this a lot, there's a change happening. When you go from Google Search to ChatGPT, is page rank doesn't matter as much anymore. It's more about the tool's actuality that JetGPT can use or search, you know, bloppy boops,

and it's indexed inside the model effectively. Some things, like, and so the way that we make decisions about a cloud infrastructure or what we deploy, probably going to change. In the same way that, like, the way that we search and consume information is changing as a result of the rise of ChatGPT, what do you think that means? Like, you kind of said this already with the dumb pipes analogy. Do you think there's something specific about, you know, the incumbent hypers that makes them incapable of making the leap in the way that you think render can make

the leap to this next generation of how agents are going to make infrastructure decisions? Like, as I type, a base 44, as an example, like, I'm going to type, hey, build me and deploy me an app and that agent's going to, like, ideally go out and find the right place to do it, right? And just do it. I don't even think about it. Yeah. Yeah.

So the way I think about this is who has the relationship with ultimately the people and the agents that are building the future? And I think that AWS has some of those relationships, a lot of those, I mean, most of the relationships today, but that's changing. We're seeing more of that and more of that come to startups like Render and others. and as more and more companies realize that they don't need this tax, then AWS stops having those relationships in the first place, and that prevents them from getting the insight that they need to evolve their products. While Render has already built years of relationships and insights that help us operate at this level, so it doesn't matter how big AWS is, we already have that lead,

And it's not just render. There's other providers like render as well. And that's how it changes. I mean, it'll take a while. It's not going to happen overnight. It's probably going to take decades. But it will happen. And then the other thing I'll say is that when agents look for tools,

then they're going to prefer higher level tools. They're not going to go configure Kubernetes. They're going to use an API that render provides. They're going to use that toggle I told you about isolating environments. They're not going to go set up two separate AWS accounts and then set up all of this other stuff that's needed to isolate environments. So building high-level tools

is actually how you win the agentic space. And that's really what render is doing. Awesome. This super rents. We have so much we could ask, but based on time, if people haven't even tried render, I'm sure people probably heard a render. But if they somehow live in a world, they'd never heard of render,

where can I find more information? Where can I sign up? render.com. Please go check us out, but don't call us render.com. We're just call us render. And yeah, we're super happy to add you to,

you know, the millions of millions of developers who are on our platform. And you can get started without entering a credit card and try us out and reach out to us at support at render.com.

We listen to every piece of feedback that comes in. And then you can always reach out to me. It's my first name, Anurag, A-N-U-R-A-G at render. Awesome. Thank you so much. An-R-R-G, it's been such a pleasure.

And some very spicy takes, including A-B-S-B-D-M-P-Pypes, which I think Tim and I both enjoyed deeply. Thank you. Yeah, what do you ask me for a spicy take? So that's spicy. Thank you. Thank you. Thank you. Thank you.

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.

Thank you. Thank you. Thank you. Thank you. Thank you. Thank you. Thank you.