The Changelog: Software Development, Open Source - Building for application developers (Interview)

Episode Date: February 27, 2025

Anurag Goel, Founder/CEO of Render, joins Adam to discuss what they're doing to solve cloud problems for application developers. They just raised $80M they don't even need and they're poised to solve boring problems like object storage, and less boring things like building for the AI era.

What's up friends? Welcome back. This is the change log. We feature the hackers, the leaders and those building render.com. Yes, today I'm joined by Anurag Goel, CEO and founder of Render. Anurag shares his journey from engineer number five at Stripe to being in a position to found and create render. We talk about how the platform works,

why he felt so compelled to build it, how they're focused on serving application developers and removing their need for ops, DevOps, et cetera, their latest raise of $80 million, and how they may spend $20 million. Just kidding. On GPUs. You may think like I did, just kidding, on GPUs. You may think like I did, they're taking on Goliath. But Honorock's perspective is that the cloud is big and there's room for everyone.

Of course, a massive thank you to our friends and our partners over at Fly. Learn more and deploy your app in five minutes at fly.io. Okay, let's talk render. Well friends before the show, I'm here with my good friend David Shu over at Retool. Now David, I've known about Retool for a very long time. You've been working with us for many, many years. And speaking of many, many years, Brex is one of your oldest customers. You've been in business almost seven years.

I think they've been a customer of yours for almost all those seven years to my knowledge, but share the story. What do you do for Brex? How does Brex leverage Retool? And why have they stayed with you all these years? So what's really interesting about Brex is that they are a extremely operational heavy company. And so for them, the

quality of the internal tools is so important, because you can imagine they have to deal with fraud, they have to deal with underwriting, they have to deal with so many problems, basically, they have a giant team internally, basically just using internal tools day in and day out. And so they have a very high bar for internal tools. And when they first started, we were in the same YC batch, actually. We're both at winter 17 and they were, yeah, I think maybe customer number five or something like that for us.

I think Doordash was a little bit before them, but they were pretty, pretty early. And the problem they had was they had so many internal tools they needed to go and build, but not enough time or engineers to go build all of them. And even if they did have the time or engineers, they wanted their engineers focused on building external physics software because that is what would drive the business forward. Brex mobile app, for example, is awesome. The Brex website, for example, is awesome. The Brex expense flow, all really great external physics software.

So they wanted their engineers focused on that as opposed to building internal CRUD UIs. And so that's why they came to us. And it was honestly a wonderful partnership, but it has been for seven, eight years now. Today, I think Brex has probably around a thousand Retool apps they use in production, I want to say every week, which is awesome. And their whole business effectively runs now on Retool. And we are so, so privileged to be a part of their journey. And to me, I think what's really cool about all this is that we've managed to allow them to move so fast. So whether it's launching new product lines,

whether it's responding to customers faster, whatever it is, if they need an app for that, they can get an app for it in a day, which is a lot better than, you know, in six months or a year, for example, having to schlep through spreadsheets, et cetera. So I'm really, really proud of our partnership with Brex. OK, Retool is the best way to build, maintain and deploy internal software,

seamlessly connected databases, build with elegant components and customize with code, accelerate mundane tasks and free up time for the work that really matters for you and your team. Learn more at Retool.com. Start for free. Book a demo again. Retool.com. Well, Anurag, I'm glad to have you here. It's been, I would say, such a journey for this conversation because I've known of you and I've known you for many years and just have not had you on this show. Now here you are. $155 million deep raised, $80 million recently announced last month.

You must be excited. So welcome finally to the changelog. Thank you. Yes, it has been a journey, but I'm really happy that we're finally having this conversation. You know, I'm such a fan of the boldness it must require and the courage it must require

and the courage it must require to take on Goliaths. And not just one, but many, right? Like Render is in the shadow and maybe now above the shadow of the days of Heroku. GCP is obviously still there. We'll talk about your infrastructure. I think you're built on the clouds. So you compete with the clouds you're actually built on too,

I imagine, but at a different level. I just admire the courage and required tenacity to do what you've done. So, and you've obviously done it well. Thank you. I really appreciate that. It is not how I think about it. No. How do you think about it?

Well, I think this is a large and important engineer in 2011 and I left in 2016 and the company did well. And so I had this opportunity to really think hard about what I wanted to do for the rest of my career. I could choose to do nothing and sort of chill out. But my wife and I both, we talked about it and I think it was, we both saw it and see it as a responsibility. Very few people are granted this opportunity to really have the freedom to pursue any goal that they want. And so my goal then became to find a really big problem that I'm also very

excited to solve and that I am good at solving. And as part of that, I ended up building applications in a lot of different domains. And I mean, even at Stripe, I had seen our infrastructure team that was managing AWS grow from, you know, when I was there, one person out of five were fully, was fully focused on AWS. That number, that percentage, about 20% stayed about the same as Stripe continued to grow, at least when I was there,

2011 through 2016. And all these people were simply managing VMs on AWS. They weren't contributing to the product. They weren't helping the other teams necessarily move faster. So that was a big waste. And then when I built my own applications post-Stripe to try to figure out which domain I was going to be interested in over the long term. It hit home firsthand. It was very obvious to me that getting something up and running

in the cloud was still very broken. Ultimately, you end up building out a Kubernetes cluster, and no one wants to do that. I'm sure there are some people in the world who love building out Kubernetes clusters and bringing all the care and feeding that those clusters require over time and spending all the money that Kubernetes ends up sucking out of your ops budget. But ultimately what people want, what I wanted was I want my application to, first of all, I want my cloud to allow me to spin up an application

really quickly and get it up and running and make it reliable. But then I wanted to scale. I want a lot of security by default around it. I want all the features that I will need as the application grows. And so the dichotomy between Heroku and AWS when I started Render was Heroku was easy to get started on,

but it stopped scaling beyond a certain point. And if you needed more than 14 gigs of RAM, you couldn't have it. Your applications were restarted every, and a lot of this is still true, your applications were restarted every 24 hours and then the price became unsustainable once you went beyond a certain scale. And then AWS was AWS just even logging in and looking at the the drop down of the 300 plus services. They have a search in their drop down. Who has a search in a drop down? AWS does.

AWS does. Yeah. Yeah. AWS does. So, and that's, it comes down to the culture of AWS, right? They were built around two pizza teams and two pizza teams do really well when they are focused on a small surface area that can be deep, but then it doesn't, it's not broad. And they end up building really amazing primitives that are stable, reliable, scalable. But then you have 300 of these primitives on AWS that you then have to go manage and integrate

and then build on top of. And the cloud has only become more complex over time. And I was always drawn to developer productivity, but then when I started spinning up all of my own infrastructure, I felt, continued to feel a draw towards infrastructure as well. I enjoyed spinning up infrastructure,

but also I knew that I was doing sort of the same thing over and over again. So when I combined those two things together, that led to Renders Genesis in 2018. And it wasn't about taking on AWS, it was about solving the problem that I had seen and in a way that made sense to me from a product standpoint. And AWS is always going to be very, very, very, very successful.

Even when Render is a large public company, AWS will still be making a ton of money. And that's because the market we operate in is so massive. And you don't have to have a winner-take-all mentality. I mean, you think about it. AWS had this massive lead, and now they're still the leader in the cloud space. But Azure and, I guess, GCP have built businesses worth

hundreds of billions of dollars coming from behind. So it just comes down to the demand and the market you're in. And certain markets are winner-take-all. Other markets are multiple people can exist and have their own unique angle on the problem. And that's how I think about Render. Yeah, it makes sense hearing that Baxter, why you didn't agree with my thing of taking on Goliath. I still think you're facing, you know, some sort of imminent threat, at least not so much today,

but in the early days, because the threat isn't necessarily the technology, it's the ability to attract a developer's attention, right? To give any care to why render, why try render, why, you know, in that case. But I think a lot of developers had this, and still do, have, haven't had this affinity towards Heroku. Heroku was the very first platform as a service to care,

I would say, about developer experience, and make it literally just too easy to ship. Right, it was just so easy. It was great. For the time, for 2005, it was magic. And you followed in those footsteps to take that magic to a new level because as you said, there's limitations.

And I know many friends who have launched their applications there successfully, smaller shops, smaller applications for a small business, so to speak. But then once you get to a certain scale, there is this limitation that was hit on Heroku. That's kind of Salesforce and other things made it not go beyond where it could have gone.

There was a lot of potential that wasn't fully realized beyond what they'd actually achieved. And at the same time, AWS kept launching service after service, because AWS launched in some ways after Heroku did, right? Because we're talking about Heroku launching in, I guess that's not entirely true. Heroku was on the scene in 2007, and then they got acquired in 2010. So they've now been part of Salesforce for 15 years. And AWS was also like S3 came on the scene around 2005 ish. But then EC2 and others. And I think Heroku could have done a better job keeping up to date with how people were building applications. And

they really missed the whole trend around static sites and containers and all the other ways in which people build applications. And that's really the differentiation. I think when you think about render from the beginning, it was about how people were building applications today and what they needed from the cloud. And then that continues. So fundamentally, the way cloud. And then that continues. So fundamentally, the way developers build applications changes every few years. And frameworks come and go, databases come and go, the way we do async processing comes and goes. And these days, it's all about calling out to chat GPT or cloud APIs and then managing all of those pieces of all this data that you're feeding to these models and then you're collecting the results and doing all of this

in discrete steps and combining all of them together at the end. So I think the cloud, any cloud should be constantly thinking about the primitives that developers need that every company ends up building themselves. And when Render started it wasn't just about Heroku, it was also about Kubernetes because every company ends up building a sort of internal Kubernetes cluster that looks very similar. People end up using the same Helm charts, they end up installing the same standards things. The problem, of course,

is that that's a lot of wasted work, and companies do it because they think that's what needs to be done. Render is saying, no, actually, what you want to get out of Kubernetes, we give you out of the box. If you want private networking, if you want auto scaling, if you want health checks, zero downtime deploys, if you automatically want to compress your responses, if you want your SSL to be completely managed for you, if you want volumes, if you want the ability to store data on a disk,

you can do all of that on render and you don't really need Kubernetes. And that has been one of the ways in which we have attracted a lot of people over the years. And in January, we signed up 110,000 developers. Is that an uncommon thing, that amount, or is that a high number? I know it's big, but is that a peak for you?

It's been a steady increase over time, but to give you some sense of where we were in July of 2022, we signed up 5,000 developers. Oh, so that's a mechs. of 2022, we signed up 5,000 developers. So that's a mechs. So in January 2025, we're at 110,000. So that's a pretty big ramp up. And by the way, all of that is through word of mouth.

It's all organic. We don't have a marketing team. I'm looking, by the way, if you're hearing this and you're a great marketing leader, please come and join Render and build out your team to help grow us faster. We're already growing pretty fast, but we could be doing better. And so-

So no marketing. No marketing. And it's all word of mouth. And that's the thing about developers. If you build something that really appeals to them, that really solves the problems that they're running into every day, you get the benefit of developers telling other developers about it.

This doesn't happen as much in other markets, but in a developer market, it's massive. And so we've really focused on the product, really focused on the look and feel, but also the kind of features that people want, especially as they grow. And our whole thing is, look, we're differentiated in two big ways. One, we're not opinionated.

Well, obviously it depends on who you're comparing us to, but we're not opinionated in how you build your app. We want you to pick any architecture you want. We're not going to tell you, look, you can only use serverless functions and have a static front end or, you know, SSR, ISR, whatever the fancy buzzwords are of the year or the month. We're not going to tell you everything is a Postgres, and you have to build functions on top of Postgres, and you have triggers that do everything for you. We want you to build your app the way you do it,

because we know that that changes over time, and we find ways in our product to support you, however you build your app. So that's one thing. The second way in which I think we're very different is what I was talking about earlier, which is we allow you to scale on the platform, both in terms of cost, but more importantly, in terms of the features that you're looking for as you grow.

So we continue to focus on those features as companies on render have grown from being just three people spending $30 a month on render to now we have folks who are spending $2 million a year on render. And they're very big in terms of their team sizes. And they've continued to grow. And the bulk of their computers,

pretty much all their compute except BigQuery in this one case is on render. And we're making sure that we continue to build for them. One thing you said that I had not actually heard of before is this idea of two pizza teams. Can you explain that? What is a two pizza team? So this is something I came out of Amazon

where back in the day, Bezos or someone at Amazon was like, look, team sizes should not exceed the number of people who can consume two pizzas. And so if you have, you know, a team of 50 people, they'll require way more than two pizzas. And so if you have, you know, a team of 50 people, they'll require way more than two pizzas. That's not great. If we want your team to be small enough, and we want their scope to be small enough, and the whole thing around service oriented architecture. So everything is a service. And then all these teams build these well defined interfaces that talk to

each other, or that people have to go assemble themselves. I mean, in some ways, that's also the UNIX philosophy. You have tools that do one thing well, and then you find ways to configure them or use all of them together. So that is essentially how AWS, and not just AWS, but I'm sure other parts of Amazon, that's how they thought about organizational design. And it's true that you ship your org chart, right? You've heard that one before but I'm sure other parts of Amazon. That's how they thought about organizational design.

And it's true that you ship your org chart, right? You've heard that one before, I'm sure. And when you think about it that way, that's why AWS isn't able to do an end-to-end application stack well. That's why they falter. And it's not something that they're going to be able to change.

But when you think about render, we're always thinking about stuff at the very top, at the very layer where we're focused on what application developers want. We don't actually build for DevOps engineers. We think they're great. They're valiant soldiers in this battle that they raise against complexity every day. But we live in a world, Render lives in a world where application engineers are responsible and want to control their compute.

So that's a very different mindset and philosophy. And it requires thinking about products in a way that is fully integrated. Because as an app engineer, I don't really want to both integrate Lambda and API Gateway and something else, and then EC2, and then Kubernetes and all of this. No, I just want my app to be out there, to be resilient, to just work, and I want reliable, scalable compute. And so that's how we think about it. And that leads fundamentally to very different products.

And I think it's pretty evident in how AWS has tried to build these products at the top level. We've all heard of elastic beanstalk. We've all heard of, you know, other attempts that AWS has made at building these higher level products and they fail. They fail. Well, failure is in quotes because at AWS the scale, any product you launch will get some adoption, but it doesn't become the gold standard for how to do it.

And that's because they always have these trap doors. When you start out with something like EC2, then your incentives for making a high level product aren't as strong because you can say, well, if this product doesn't work for you, you can always use EC2. And you still make money that way. For render, that's not true.

We're not selling VMs, we'll never sell VMs. Our platform is what we are selling. So like, if this doesn't work for you, then we lose a sale, so we make it sell VMs. Our platform is what we are selling. So like, if this doesn't work for you, then we lose a sale, so we make it work for you. So that's again, a philosophical difference. Yeah. You want the entire application to be there and you want it to use Cron jobs,

you want it to use managed Postgres, you want it to use different services to enable that application developer to have the autonomy to deliver their application and not have to go through an intermediary, which is really the DevOps world, right? Like you're cutting that out, not so much because you don't like it,

but because you're trying to serve a different sliver of the developer marketplace, so to speak. As you said before, was that the cloud is big, there's room for all basically, and you're gonna have AWS winning, you're gonna have Azure winning, you're gonna have GCP winning, but you're not gonna win,

they're winning in different areas, they're winning different types of teams, maybe larger enterprises that have uniquely different scenarios where they literally have to have a DevOps team because their business requires them to operate a different way. I don't know That's that's kind of how I look at it one thing you said actually in In your acquisition sorry on your acquisition in your announcement, I should say

Of this 80 million dollar funding that you just announced back in January Congrats, by the way. Thank you You said most Most struggle to maintain focus today because they face an impossible choice with cloud infrastructure. You're going to say they can either use legacy simplistic cloud platforms that fail to scale and constrain their technical choices,

or they could dedicate substantial resources, AKA using AWS, et cetera, to manage unnecessary complex infrastructure on public clouds. And they burn through precious time, resources, and ultimately just like delay time to market, delay their application from existing. Render is in that middle ground there.

And you said before that you were number five to join Stripe, so that means that you probably exited well with some deep pockets. You didn't have to go back to work. You said you and your wife said, Hey, I'm paraphrasing some version of conversation you probably had. What should we do here? Should we just hang out on this beach or should we go and solve some problems? What made,

what made you want to be in that middle ground there to put render in that gap that you described to solve this problem? Like why not just go off on the- Chill out. Yeah, chill out. Why not? Why go back to work and I'm sure you work hard, right? Like you probably work 50, 60 hours a week or more.

I don't know. Why? You don't have to. You didn't have to. So I often ask myself that question. Is that right? I bet you do. You're like, gosh, did I really have to do this?

There are days when I ask myself that question. But no, I think, first of all, you know, we were both young when this happened, right? And eight years ago. Yeah. A little over eight years ago, but yeah, but it's so, so like we still had our lives ahead of us and, and I think for me, at least it came down to who I am fundamentally and, and I am driven by impact.

And I get bored when I am not doing stuff. And I'm also just fundamentally somewhat boring. And by that I mean- As a person you mean? As a person. Okay. In that I don't have, you know, these sort of Renaissance hobbies

that I could spend a lot of time on. And you know, I could go sculpt or be a carpenter. Sure. Or yeah, like a lot of people try that. You know, that's almost like a meme in the Valley where like, okay, well now I made this money through this whatever company and now I'm gonna go be a carpenter for a little bit.

Okay, I didn't know this meme. I love it. People do it, but I think there's also traveling, like you spend all your life traveling. I'm a reluctant traveler. I don't actually. Is that right? Yeah, I don't love traveling. Is don't actually. Is that right? Yeah.

I don't love traveling. Is it the plane? Is it the people? Is it the, what is it? You know, I've got a great setup at home. I'm comfortable. I'm comfortable. All right.

Yeah, exactly. I know where the bed is and I like it. I like it. I have all my stuff here. I enjoy it. I have my routine. No, so, you know, jokes aside, I think there is something about fundamentally who you are and what drives you. And for me, it was important to, again, like spend, I want to look back at the end of my career

or my life and be like, I contributed to solving this large problem. And I know that that will make me feel good about how I spent my time. And so that was what eventually led me to this search. Can you tell me about, if you don't mind, a layer deeper, your wife. Is your wife in technology? I'm not familiar.

What's her background? How could she contribute to, yes, Anurag, you should go back to work and build this platform that will eventually, potentially, and as you said before, will IPO. I mean, that's a audacious goal, and I think you're probably gonna get there. Not so much what is our qualifications,

but does she have some awareness of the true requirement to do what you've done? Oh, she does. So she knew what Stripe was like, right? She knew how hard we all worked. She had seen all the early people go through everything that we went through. So it's very clear, we knew what we were getting into. And I think it's just the nature of our relationship where

what's really important to the other person is important to me, or what's important to me is important to her and vice versa. And we've been together a while. We're, I think it's gonna be 18 years. Oh wow, congratulations. Thank you, yeah. You must be doing something right then, because that's a long time.

It is and it feels like it's also, it's like it doesn't feel like 18 years, it'd be like, you know, it's just, wow. It's, you look back and now that's 18 years. So- Do you like Bob Seeger by any chance? I don't, I've heard of him, but I- There's just one phrase from one song he has,

20 years now, where'd they go? 20 years, I don't know. I still look at myself sometimes where they've gone. But essentially this idea that, wow, 20 years have gone by so quickly. You know, and you're alluding to a version of that. I still remember the first time I saw her. I have like very distinctly, I have that memory in my head.

And she thought I was a snob. She listened to this show? She's probably listening to this show now. She's tuning into this chapter at least. She's probably gonna listen to it, yeah. So I'm probably gonna get some brownie points, but no, I do remember the first time I saw her, and she thought I was a snob when she first saw me,

and it was for a variety of reasons, but then I fixed it, it was fine. And here we are, 18 years later. Cool. Well, you know, it's good to be equally yoked in a decision like that because like I can only imagine that, you know, you had a choice to go back to, you know, in quotes work, to climb another mountain, you know, and obviously once you begin the climb, it would not make sense to even start the climb if you're not gonna finish the climb, right? Oh yeah, of course.

So why would you go and even start if you're gonna quit or decide to change that decision a year or two into that choice? It just doesn't make any sense, you know? You alluded to the potential of an IPO, so your focus is on IPO-ing, render? Well, my focus is on continuing to solve our customer problems.

Of course. And growing revenue and doing it in a way that allows me to keep render an independent entity and for me to have enough control over what we build and how we build it and to work with the people I want to work with. And all of that essentially means staying independent of the very long term. We also raised all this capital and we have responsibility to make money for our investors, for our employees. And so all of that I I think, does naturally mean

in today's environment, an IPO. But that's just like a step in the long-term journey because one thing you realize is like the IPO, post-IPO, I'll still have the intensity of problems that I have today, they're not gonna go away. We'll just have a different set of problems. You just go faster. It never gets easier.

This is this is this famous cycling quote. And it doesn't, it doesn't get easier. We've raised all this money. In some ways, my life is harder than it was when I wrote the first line of code for Renderer. And it's harder because I have to constantly reinvent my job every six months and learn very quickly and learn a lot of stuff that has nothing to do

with engineering on how to run a company. And that's never gonna change. So the IPO is just a step in that journey. We're nowhere close to an IPO, but the way I think about it is long-term, this company should outlast me. And we talk about it internally as this being a generational effort.

And all of that points to staying independent because we've seen what happens when you get acquired by Salesforce. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah. Yeah.

Yeah. Yeah. Yeah. Yeah. Yeah. Well, before the show, I'm here with Jasmine Casas from Sentry. Jasmine, I know that Session Replay

is one of those features that just, once you use it, it becomes the way. How widely adopted is Session Replay for Sentry? I can't share specific numbers, but it is highly adopted in terms of, if you look at the whole feature set of Sentry, Replay is highly adopted. I think what's really important to us

is Sentry supports over 100 languages and frameworks. That also means mobile. So I think it's important for us to cater to all sorts of developers. We can do that by opening up replay from not just web, but going to mobile. I think that's the most important needle to move. So I know one of the things that developers waste so much time on is reproducing some sort of user interface error or some sort of user flow error and now there is session replay. To me it really does seem like the killer feature for Sentry. Absolutely that's a sentiment shared by a lot of

our customers and we've even doubled down on that workflow because today if you just get a link to an issue alert in Sentry, an issue alert for example in slack or whatever integration that you use, as soon as you open that issue alert, we've embedded the replay video at the time of the error. So then it just becomes part of the troubleshooting process. It's no longer an add on. It's just one of the steps that you do, just like you would review a stack trace. Our users would just also review the replay video. It's embedded right there on the issues page.

Okay. Sentry is always shipping, always helping developers ship with confidence. That's what they do. Check out their launch week details in the link in the show notes. And of course, check out Session Replay's new edition mobile replay in the link

in the show notes as well. And here's the best part. If you want to try Sentry, you can do so today with $100 off the team plan, totally free. If you try out for you and your team, use the code change log, go to sentry.io again, sentry.io. Let's, uh, let's examine that. Can we examine reinventing your job?

Uh, you're, you know, what you do. Let's examine that. Can we examine reinventing your job? What you do, can you describe, I imagine early on, CEO is just simply label. Obviously, somebody has to hold that title in an organization. Can you walk me through, I assume now you're far more CEO than you were first line of code, right? Can you walk me through the I assume now you're far more CEO than you were first line of code, right? Can you walk me through the steps of reinventing the role that you've fulfilled? Yeah, absolutely.

And even learning that that is what you need to do is a journey. And so I didn't know when I started the company that I would need to reinvent my job every six months. And I think for the first at least two years, actually longer, the bulk of my time was spent on essentially IC work, where I was coding and the rest of my time was hiring. And I think early on in a startup journey, the CEO has three jobs. They have to raise capital, they have to hire, and then they have to build product.

And whether they're technical or not, they have to build product. And that changes over time. And so for me, as you hire more people, it becomes clear that, especially as you raise more money and you're able to continue to hire people, it becomes clear that the organization needs a different set of things from you. You need to start thinking about planning.

You need to start thinking about how all these individuals are going to start working with each other in a way that is driving everyone in the same direction. And you think about management and you think about hiring managers, but also, well, okay, what are your expectations for the managers? How do you even evaluate managers? And how do you make sure that they aren't actually slowing your engineers down? How do you think about the rest, the non-engineering and product side of the org? So for the longest time, I was the only person

responsible for quote unquote product at render. So the company started in 2018. We launched live on stage at TechCrunch Disrupt in 2019, Battlefield, which we won that year. That was kind of insane. You still have that big check? Yeah, it's in here somewhere in the office. You don't have to get it. I'm just curious.

I'd love to see a picture. If you can, as sort of post promotion of this show, I'd love to see a picture of that check on social media as part of this. That'd be awesome. Yeah, of course, I'll send it to you. That was kind of crazy. Like you obviously see this stuff on TV.

Silicon Valley, the TV show, man. I mean, like, come on. Yeah, it was. You were the you were the Pied Piper in terms of the winner not so much the actual application and maybe the exact thing was happening but you got the check and you won the battlefield round it was less dramatic it was just a lot of hard work I'll say and you're on stage and you know there's all these incredibly accomplished people

and Ashton Kutcher and... And Ashton. And Ashton. That's hilarious. And it was quite an experience. But I think at that point, Render was actually just four people when we won in 2019. And we launched the thing.

And then when you launch it, once you have customers, things just feel very different. Once you have people who want more things from you, then you have to get out of build mode and you have to really focus on listening to them. And being sort of my job was much more around, okay, well, what do people need talking to them, making sure that I was steering the company, the product in the right direction, while also building it on the side. And then we hired

our first product person who is our VP of product now in December 2022. So for four years, we didn't really have a product person. It was just me and the other engineers, which I think served us well. But at a certain point, you have to start thinking about the other functions you bring in. So then you think about bringing in finance. You think about bringing in someone

to manage your people team. You think about bringing in marketing, but that never worked for us. So, well, that's the other thing, right? How do you grow this thing? And I think we were lucky in that we kept growing despite not having any marketing or sales. And so, especially in the early years,

it was that I thought and building the product and getting, allowing people to scale on the platform and giving them what they want was front and center. I think now we've raised all this money and we have 80 ish people in the company. And we're growing fasth people in the company. And we're growing fast. We're hiring fast. And our, my goal now as CEO has switched to repeating myself over and over again, to make sure that we're all aligned around the same kind of thinking around what we're doing, why we're doing it, who we're doing it for, and what needs to be done.

And that, the CEO's job becomes just constant messaging and repeating the same message over and over again once you get to a certain size. But it also becomes hiring, I mean, hiring executives is, you talk to a bunch of CEOs in my position, everyone is going to tell you hiring executives is hard. And it is also the highest leverage thing you can do. And that is a lot of what I spend my time on hiring and making sure that we're all moving

in the same in the right direction that everyone knows why we're doing what we're all moving in the right direction, that everyone knows why we're doing what we're doing. Because it turns out, all the people who joined early on, they knew what we were doing. They didn't need to be told, they just went ahead and did it. But then the 80th person you hire has a very narrow view of the organization by default.

They're coming in into a specific team, they have a specific project that they're taking on, but the whole architecture of the stack is much bigger. And so you still want them to have the autonomy to make the right decisions day to day. And the only way they can make the right decisions is if they have the broader context. So sharing context,

sharing everything that they need to do their jobs well, that becomes your primary responsibility. Wow. So it sounds like you must have gone through a period where, I imagine you don't write code too frequently today. You don't write a lot of code, I imagine. I wish I did. I mean, if that's true, then why did you do what you've done? frequently today. You don't write a lot of code, I imagine. I wish I did. I wish I did. I mean, if that's true, then why did you do what you done?

I mean, like, I understand you're being facetious to some degree, somewhat rhetorical in that response. No, it's a good question. I wish I'd, I wrote, so here's the thing. I wish I wrote more code on the weekends, just on the weekends. I don't wish I wrote code day to day, but my weekends are spent doing other things. What do you do on the weekends? I'm spending time with my wife, man. Okay, I get that.

I mean, you never know though. You never know. You could be doing something like a side project just to keep you warm, just to keep your skills refreshed and whatnot. Yeah, so I need to get into that for some reason that hasn't. I think I'm just in a state of trying to recharge all the weekend. I actually end up playing video games on the weekend.

Real time strategy. Oh, man. Do you build machines? Do you build your own gaming machines? I did build my own machine and I still use it. How long ago? Recently? No, that was 2016 when I built this startup, well if you can call it that, it was a one-person startup that I ended up selling to another company but I built the first GPU backed Jupiter notebook online that you could start with a single click. And it had all these data scientists who were really running into tons of trouble trying to spin up a Jupyter notebook back by GPU to do deep learning,

which was the craze back in 2015, 2016. And I saw that, and I was taking one of these courses where you have, you know, I wanted to learn deep learning. And so this was my exploratory period. And then I realized that this was insanely hard for most people. And I went and built a whole thing on top of Kubernetes, no less,

to offer people a one-click Jupyter Notebook. But then, you know, Google came in and they were like, hey, we'll give it to everyone for free. And to be completely honest, I didn't care as much about data scientists as I care about developers, application devs. And to be completely honest, I didn't care as much about data scientists as I care about developers, application devs. And so then I started working on render and I was like, I don't, I don't

want to do this thing anymore. So then I sold it through a tweet. I tweeted about how I am now focused on something else and there's 10,000 data scientists using it. I would love for someone else to take it over. And then there's this company called Doc.ai and they acquired it from me for a relatively small sum. And I was happy.

So how does that relate to you building your own gaming PC? Oh, so I needed to run deep learning on my own GPUs. And so it wasn't intended to be a gaming machine. It just became a gaming machine later. Cause it had no more use. Cause later because I had no more use because yeah I know he's I wasn't doing I got this GPU this massive GPU and I had two of them I built a 2gp machine. Yeah, I think it's kind of crazy how that

swings back again because And we could probably touch on this to some degree when we get to you know You're focused now with render on AI and what that means in your announcements, I have some questions around that, but there's this new resurgence to, especially with Olamma and public and or open LLMs to be used and consumed in your own private, in your own private inference essentially.

Finding a GPU, whether it's an older gen like a 3090, which is still relatively useful, 4090, which is, you know, one of the most earliest models in the now 5090s. Those are all like the top tier of Nvidia's RTX level GPUs. Like good luck finding those things, right? Good luck finding them.

And if you do They cost just as much as the original price tag if not more, you know, because there's such a demand for them I gotta imagine that's a It's wild. I'm just kind of crazy because I feel like it's kind of crazy that It swings back again. You were playing with that You know and maybe instead of render I guess maybe now you're your best positioned to maybe pick that that back up again because I imagine part of this innovation you're talking about in your

announcement post which I'm sort of paraphrasing let me see if I can pull it up real quick just I can be more clear about it you mentioned you allude to the new chapter for render and then the desire to build for the AI era. I imagine when I read that, I think you're going out to buy a bunch of GPUs. Okay? And you're taking a lot of that 80 million or a large chunk of it and you're like,

okay, this 20 million is for GPUs considering the price tag I just mentioned for your brand, you know, you're sort of like consumer, prosumer level GPU. I imagine building for that AI is tech on top of it, software and orchestration on top of it, but it's ultimately acquire GPUs, plug them into machines and make them available. So it's actually not that. Okay. Yeah.

So again- My assumption is incorrect. Well, it might become that. We don't know, but we don't have enough evidence to say right now that that is what we should do. But I think it goes back to how what I was saying earlier about people changing how they're building applications. And we realized early on in 2022 that our customers were not the kind of customers who were going to go train their own models. And we're not selling, Databricks is not using render or Grok 3 is not built on render.

We're selling to application developers and application developers are not in the business of training their own models. They use chat GPT or cloud or whatever and they build on top of that. We did a bunch of customer research because in 2020 we were like, well, should we go buy a bunch of GPUs? And you and I both know of companies that are peers that went and did that and then realized a bit too late that they shouldn't have done it. But we knew early on that this was not the path for us.

And I'm not convinced that that has changed for us. So when I talk about what we're doing for how people are building apps in the AI era, I'm thinking about the ways in which we can make it easy for people to run a lot of distributed compute or compute that requires a lot of retries or compute that is based on a lot of different conditions. Temporal then, you're trying to build what temporal's built.

I can neither confirm nor deny that statement. Well, that's what you just said. I can confirm that by what you just said. Well, I think there is an opportunity for us to build something that makes that kind of problem a lot easier to solve for application developers. Exactly. Yeah.

Well, if you don't, your application falls over, right? You've got something waiting, so your application's blocked. You need to have that resilience. Exactly, exactly. The stack doesn't, you have to build yourself. Or, not an ad, they're a sponsor of ours. I'm aware of how their platform works.

But they may actually sponsor this episode. I don't even know, because we don't know which episode is being sponsored when we produce it. And that's totally fine, because I think Temporal's a great product, but again, it requires a lot of wrangling, and it requires a lot of figuring out. And render is really good at making complex things easy and giving people

an interface that they like to use and that they love talking about. And that's our strength. And when you combine that with our strength around running millions of applications at scale reliably, then you kind of see where this is going. But that doesn't rule out render offering GPU inference. Again, model training is not where we would focus, but you can imagine you still can't run inference, serverless inference in a way that is, I mean, there are

places where you can go do it. But the other thing we realized for render is people generally want everything in the same place, to the extent that they can. And render is never going to build literally every single service that AWS has built. That's not who we are. That's not the way for us to win. But there is a core stack that we target.

And it goes back to the components that everyone needs or that 80% of the market needs. What does that mean for what render provides for that component? And so one of the things that often comes up, especially for AI companies, is object storage. They're running all their other compute on render. They want to manage inference on render, but they also want to store other compute on render. They want to run in managed inference on render,

but they also want to store their models on render. And they want to like deep seek, you store the model on render, you run managed inference against it. Render doesn't have object storage today. People can use S3 if they want. And they do use S3 while they're using render. But we consistently hear from people,

look, S3 is the only part render, but we consistently hear from people, look, S3 is the only part of my stack that is on AWS, and I would love for you guys to fix that. But it's been a while and we've chosen not to build S3. It's kind of funny, your next innovation is like the oldest tech, basically. Yeah, the thing that AWS built first. Yeah, I mean, it's what they're most known for.

They've won it so much that S3 compatible is the way. You know, like, I'm sure that when you build your object storage, you're going to make it S3 compatible because you have to, right? Absolutely, yeah. But again, it's not... So the way we think about product is not to build technology for the sake of it. It's to build technology to solve the very real problems that people have.

And that might lead to what from the outside might appear to be sort of a boring platform, but our numbers say otherwise, and our revenue says otherwise. Well, you need to follow that boring tech mentality too. I think there's a certain recipe of innovation, and there's a certain recipe combining that with boring. Boring is stable.

Boring is stable, boring is secure. Right, boring is capable. Yeah. It's not gonna fall over necessarily in the middle of the night and cause me and my team headaches because that shows, renders super innovative next thing. It's more like, well, that's kind of funny that your next innovation is object storage. Okay, so you've got, you currently have GPUs running, so you're running inference. So people are pulling up.

No, we're not. Okay, you're not. No, no, I was just saying we can't rule that out so okay so some of that 80 million might go towards figuring out the GPU situation do you think it'd be 20 million dollars I was just joking about that number but man I can imagine if you had to stack some GPUs it probably be about 20 million dollars to to a proper setup yeah I don't know I I don't want to spend $20 million on GPUs. Who does, right? Like, guys.

Yeah, who does? Because like two years from now, three years from now, when the demand curve swings back, you'd have probably paid, you know, 3x, 4x more than you should have. Yeah, but the good thing is there's a bunch of people who already spent that money on GPUs and they are looking to make some money from it because they're just lying there being wasted. And so there is a marketplace approach to this and there are companies that are becoming effectively GPU marketplaces. SF Compute is an interesting company that we've come across recently. And so we don't have to go buy our own GPUs.

And there is a world in which we test the waters by looking at some sort of marketplace approach. So without revealing or me asking you to reveal too much of your cards, or even beyond my question mentioning Temporal ever again, in terms of this in particular, are you, is the next thing you're trying to build that retry world where you don't have

an application fall over, is that, I mean, because going back to your original state, which was, or at least in your, that I paraphrased from your announcement post, was like you got this one camp that hangs out in legacy, and this other camp that hangs out in public cloud, that they have to build everything. And there's this middle layer,

which is called render, which we've been talking about, of course. And that's where some of the orchestration is done for, on behalf of an application developer. There's application developers that wanna utilize APIs, whether they're for artificial intelligence, inference, or whatever it might be. They're using APIs every single day in their application,

but they've got this problem. And you essentially watch that with cron, or background jobs, or cues, and you've gotta manage those orchestrations. You've probably got dashboards and logs, just like pager duty and whatever you might have. So I imagine, can you give me a peek into what you're doing to solve that problem?

Yeah, so the way people manage it today is exactly what you said, which is you run a background worker and you have a Redis queue and you run something like Celery or whatever. And I think again, that architecture served us well, you know, for maybe 10 years, but it's showing its age based on the new kinds of

requirements that a lot of applications have if they're tapping into these long lived API calls that are streaming data, web sockets are becoming increasingly more relevant. We have a lot of people move over to render from Vercell because we have web sockets and they can run Next.js in a way that allows them to call out to these LLM APIs. And so, but when you think about APIs. And so when you think about not just for AI APIs, but even async tasks, things that need to happen, you need to make sure that they happen once and only once. And then you need to have conditional events happen. And so you basically build out a whole graph of activity. And you want to be able to just express that in your code.

So you just want to say this function, this is my job. Run it once, that's it. I don't want to care about anything else. I don't want to spin up background workers. I don't want to spin up queues. You do all of that for me. Make sure it's reliable. Give me a dashboard that tells me exactly how things are going, give me observability into it,

and charge me only for the time that my task is running, and give me different levels of compute depending on the task. I can tell you what level of compute, and maybe you auto-scale compute vertically depending on the task. There are a lot of these questions and answers that we are thinking about as we think about this next product. And I think it's really exciting. I think it's fundamentally changing the abstraction level of how people run a bunch of distributed tasks and making sure that we give people the same,

again, it's all about what your infra team would do for you. If you're on AWS, your infra team would set up temporal and they would train you on how to use temporal and then developers would have to learn temporal. We're replacing a lot of that, right? And we're saying, again, application devs, if you want all of this, here it is. And you don't have to worry about

how many temporal workers you have, whether they have enough memory, whether you need to increase the number of temporal workers you have. So there's a lot of that just unnecessary work that even we have to do to deal with something like temporal. But I think temporal is a great product.

And I think that they serve this growing market, this need that they're not unique. They're not never going to be unique in serving if it's a market that is a problem that everyone faces. Are you friendly with other CEOs? Depends on the CEO. Are you friendly with Samar, for example? Temporal CEO?

I don't know him. I don't know him. Okay. I've talked to him before. You guys seem passionate about solving this problem. So I bet you guys will be good friends. Sure. Yeah.

Yeah. I mean, again, I think what they've built is great. You know, I think, yeah, it's, when I look at what you should focus on, it seems in my prior examinations of what I assumed render was, and then now my examinations of what render is based on this conversation with you, you look at the marketplace of being a developer,

in particular an application developer, because that's who you serve, and you say, what problems does that kind of developer have deploying applications? And let's just solve their problems. And then you pick one product after the next, after the next, and you just keep layering on until you have a full suite of essentially

batteries included, configuration not required, it's conventional for configuration, here you go. A lot of great choices, now you can fine tunetune if you want to it's off the beaten path But here you here's the blessed path application developer go have fun deliver your application You just described our business strategy. Yes. There you go. That is that is exactly what it is. Okay so when it comes to I suppose this If you want to say this 80 million that you've got, did you need that money?

Did you need to raise another round or did you do it because it was time, it was necessary? You know, why raise a Series C? Why that for you all? I know you had to innovate. Do you need that cash to sort of accelerate certain things? Cause that's usually why you raise cash, is to accelerate a new plan.

Yeah. So I think for us, there were two big reasons. One, increased legitimacy. I think there are a lot of people who, both customers and potential hires. Perception essentially. A lot of it has to do with perception because you look at a CSE company and they have this product and it might be great,

but they're like, CSE companies die at a much higher rate than CSE companies. Everyone just knows that, right? And there are people who will join a CSE company because it has reached a certain level of product market fit and has reduced the risk to a large extent, but they won't go and join a CEC company. And so it was important to us to continue to have this public perception of stability and long term viability given what we do. and long-term viability given what we do. And as soon as we announced around the number of people building serious things on render, that has taken off.

So there's that. Okay. How do you maintain an awareness to that? Answer the rest of your question then come back to that one. Because I wanna hear what you're saying. I was just thinking about that in the moment. I'm like, gosh, how do you,

how do you pay attention to the serious applications or not serious applications, you know? But anyways. Yeah, I'll get to that. Yeah. But the second reason is, of course we, like we, we need the money to hire more people. I need to build out a marketing team. Yeah. Marketing and sales.

We don't have, like we have one, again, a lot of people might not be interested in RenderApp or hearing this, but we have one account exec, that's it. If I was a salesperson who had no job or wanted to transition to a new job, I would kill for that job. You know why?

I can make all the money. Or a lot of money because if you got one across, I don't even know what your revenue rate is, but I'm sure it's gonna grow at being a Series C. Well, I mean, that's a great place to be and as a salesperson or any kind of executive is to be in a position where you can collect. Yeah, but the thing is most people who use render

never need to or want to talk to sales. And so... Sad. I mean, sad for the salesmen. Well, I think that's the way to go, right? You want to have that sort of on demand to the application developer. That's the way they think. Like an application developer is not going to want to sit down with somebody.

However, sometimes they're going to need to convince other people, and that's where the AEs come in. It's like, hey, I'm an application developer in my company, but I have to have my CTO's approval, and he has to meet somebody, or he or she has to meet somebody at Render to legitimize, you know, this spend or my ability to even give it a POC. Yeah, and we have a sales engineer, also just one sales engineer.

And so I think part of it is just, there are people who just want to talk to someone, like you said, and it might not even be to legitimize it to anyone else, it would just be for their own comfort. And we- A real email address, a real person. Yeah, a real person, they want to get a zoom call. They want to make sure that they hear from someone

how things are going to go. And then they have this person's contact now. And if things don't go well, this is the person they call, right? And so there is that level of human interaction that a lot of people need to feel comfortable about trusting their entire business over to us, right? Because we're not building a tiny thing for them.

We're running their entire business online. And so that's why I think it's not even sales. It's essentially help and education. And we don't have this like, oh, you need to meet this quota. As a salesperson, we don't have that because a lot of the self-serve people will reach a point and then they'll be like, Hey, I need to talk to someone. And, and then, you know, sometimes like, do we count that in sales comp? Do we not? That's an interesting question. And a lot of people migrate to us from a place like Heroku AWS, and they self-serve migrate. But during that process, they're going to migrate

anyway. But during that process, they do feel the need to talk to someone. And so that is probably sales assisted. And so you count that in their quota. But it's too early for us to set quotas, given that we don't effectively have this. But to go back to your question about the money that we're raising, we do need to build more things faster. We're going to do that. So it's not just marketing and sales. Actually, a lot of it is going to go towards hiring more engineers and hiring people who were not accessible to us just because we were an earlier stage company. You also, you were asking about the other question

that you said you were going to come back to. How do you pay attention to? Yeah, how do you pay attention to a serious application? Yeah. Yeah, yeah. Honestly, the simplest way to tell is they use their work email and they're not using a Gmail address.

So not a Gmail account or not a AOL or ICQ something that's just basically not. I don't think ICQ ever had emails, but yes, AOL, yes. Is ICQ still around? I don't think so. I fumbled that one. It should have been ISQ. It should have been like Earthnet or something like that. Earthnet, or CenturyLink.

Yeah. Something, sbc.net. SBC.net, like your ISP's email. Who in the world ever uses their I... Bell, yeah, exactly. Precisely. Exactly, anyway. Slight tangent. So yeah, so not having any of those emails and having a work email makes sense. But we also have a lot of people using render for specific

things while working at large companies. Like we have people who have signed up with meta.com and we have like alibaba.com and all these other, you know, even Amazon and Google, these are paying customers, people have signed up with their work email who are not actually running a large thing from Google or Amazon on render. It doesn't make sense to do that, but they're using, so these might be like data scientists who want to run something in Python and they just can't get the support they need from their DevOps teams. And this is very common in large companies

where you have enterprises where everything, their main application is handled by the DevOps team, but then people want to build other things, whether it's data scientists or sales engineers, even marketing engineers, they want to do stuff that they want to put out in the world. They wanted to have a URL that other people can access, and they just don't get the support that they need

from DevOps because DevOps couldn't be bothered, and they're a bottleneck because they have all these other needs that they need to fulfill from the main application. So we get a lot of people like that, but fundamentally the people who we're most excited about today are early stage startups because Render is a great fit for them. When you're a startup, a great fit for them. When you're a startup, you wanna move fast and you want reliability and render gives you both of those things. And then the second sort of serious customer segment

is what we call tech enabled businesses. So tech enabled businesses are those where the core competency isn't actually software. What they're doing is something like they're building a mortgage CRM or they're a law firm and they need technology to achieve a specific goal or they are a, in some cases also like a crypto company that needs something specific and they need to host online, but they're not in the business of hiring DevOps engineers. They don't even, they might not even be able to hire DevOps engineers. And so they are very, very happy with what render and products like render provide.

And then we have I think we're increasingly seeing what I was talking about earlier where there are these teams within larger companies that end up using render because it gives them the same speed of you speed of iteration velocity we also because it gives them the same speed of iteration, velocity. We also just launched things like SSO and SCIM. Finally, huh? Wow. I know, yeah.

Cross that chasm, finally. Yes, so every startup wants to change the world and we're like, we're gonna change the world. And then the customer's like, do you have SSO? And that's, everyone ends up building it. So here we are. And we actually built it ourselves. We didn't use one of these,

one of these companies that everyone ends up using for a variety of reasons. Also like our engineers are great. They want to build this stuff. So it's now available in early access. It'll be fully available in a month or so. But there are these companies that want this level of compliance and they want this level of security.

And so SOC 2, ISO 27001, HIPAA, we're working on HIPAA. It should be available this fall. So actually this late spring is when we'll be ready to work with companies that require HIPAA. So all of that indicates different levels of seriousness. Yeah, I assume. Yeah. Well, you're a serious company now. You have to have this enterprise level feature set. I mean, right? You have to. Because now you're going to attract these folks and it's a no unless it's a yes on those two fronts or those fronts. Yeah, exactly. And it makes sense because you don't want to go in and remove...

A lot of SSO is really about offboarding. People don't want SSO for actually single sign-on data. Security departments don't care if you use Google to sign on, although, I mean, they might, but fundamentally it's about control of who can access this app, and especially if something like your infrastructure. And so as soon as someone leaves the company,

you wanna make sure they don't have access to your most secret and most critical infrastructure, right? Yeah. And so SSO is really about offboarding more than anything else. And so you have to build that in. And then you have SCIM where you add someone, they automatically get added, and you offboard someone in Okta, and they automatically get offboarded from Render and all of that.

And your assigned roles and permissions, all of that becomes pretty important as you become a serious company. So you built it versus bought it. How did you, were you personally involved in that choice? What was, what made you build versus buy? I was personally involved to the extent that when they first said they were gonna build it, I was like, why?

And yeah, that was my first step. As you should as a CEO, you're like, why? Yeah, I was like, why? Because we can buy this right now. Because we can buy, yeah, exactly. And our VP of engineering, Mike, was the same. Like he was also like, why? Why are you doing this?

So then, but then actually when we dug into it, and I didn't dig into it, but other people did. And part of it is also that, you know, we're, it's like, we're not one of those B2B SaaS companies where you are signing up, you know, a few hundred people every month or whatever. Like we were signing up all all these people, right? A hundred and ten thousand people.

Terminus amount of people, yeah. And render's the kind of thing that will require a lot of SSO seats, so to speak, once you get into an organization. So we wanted to make sure that we weren't spending a ton of money. But also a lot of these things work well. So if you have like Okta or Auth0 or Stitch or WorkOS, they work really well with SSO

if you've also integrated your Auth with them. And we were not going to move our Auth over to them. And part of that was just because we have built a strong auth system and we need to integrate our auth with our own GitHub auth plus GitHub permissions for your apps. And there's some complication there. So it's not just plain auth. And also, again, we're not going to pay them for 110,000 signups a month or 120,000 signups a month, right?

And so it just didn't make, first of all, it didn't make economic sense for us. I'm sure it makes economic sense for most companies, which is why a lot of these companies exist and are doing well. But for us, it just didn't make sense. Plus the team that was building it, they'd built it previously at Figma. So they were just like, hey, we just did this at Figma. We can go do it again. And they did. They built it really quickly and it works.

And I'm sure that we'll continue to improve it. It's still in early access, but I feel good about it. Just curious, really. I don't really care about the number necessarily. I'm just sort of curious of if you saved, which I imagine you did, was it dramatic? Was it a dramatic savings to build it yourself and to have control?

Because I imagine the reason why you did it was because as you said, you have people on your team that did do it recently, and so it's fresh to redo again. So why not? I imagine you have some autonomy and control over, you know, your choices within implementation that is unique to the platform. So you have a bit more controllers,

and maybe in other scenarios, you may be a bit more restricted potentially. And then obviously there's the savings because now you don't have the monthly bill based on the user count. I think all of those things are true to varying extents. The biggest thing was we had this existing auth system and we just didn't see enough value in using these things

for just SSO. And it was a big risk for us to switch our auth over to the new provider. Well, friends, I'm here with Samar Abbas, co-founder and CEO of Temporal. Temporal is the platform developers use to build invincible applications. But what exactly is Temporal? Samar, how do you describe what Temporal does? I would say to explain Temporal is one of the hardest challenges of my life.

It's a developer platform and it's a paradigm shift. I've been doing this technology for almost like 15 years. The way I typically describe it, imagine like all of us when we were writing documents in the 90s, I used to use Microsoft Word. I love the entire experience everything, but still the thing that I hated the most is how many documents or how many edits I have lost because I forgot to save or like something bad happened and I lost my document. You get in the habit when you are writing up a document back in the 90s to do control S, literally every sentence you write. But in the 2000s, Google Doc doesn't even have a save button. So I believe software developers are still living in the 90s era

where majority of the code they are writing is there some state which needs to live beyond multiple request response. Majority of the development is load that state, apply an event, and then take some actions and store it back. 80% of the software development is this constant load and save. So that's exactly what Temporal does. What it gives you a platform where you write a function

and during the execution of a function of failure happens, we will resurrect that function on a different host and continue executing where you left off without you as a developer writing a single line of code for it. Okay, if you're ready to leave the 90s and build like it's 2025 and you're ready to learn why companies like Netflix, DoorDash and Stripe trust Temporal as their secure scalable way to build invincible applications, go to Temporal.io. Once again, temporal.io. You can try their cloud for free or get started with open source. It all starts at temporal.io.

I guess what's next? I mean, you're spinning up marketing. you're spinning up, you've crossed, or in the process of crossing the enterprise chasm, which is to offer SOC 2 compliance, et cetera, attracting, you know, letting this series C be the, you know, the financial boom, let's just say, or fuel to the fire, as well as the legitimacy to attract newer types of customers. I guess, how do you go from here?

Where do you go from here? Like, this raise was just last month, and your job is reinventing itself time and time again. I imagine this raise may give you one more variation to your personal role of reinvention. Yeah, I think I expect the next year, for me personally, I'll end up spending both externally and internally sharing vision and strategy and talking about render. And like I told you, I'm a reluctant traveler, but I've already got business trips lined up this year. Okay.

That I just- You coming to Austin at all? Not yet, but I'd love to. If you're coming to Austin, I'd love to meet up, man. That's where I'm at. I would love to. If you're coming to Austin, I'd love to meet up, man. That's where I'm at. I would love to. Absolutely would love to grab a beer. But yeah, I think my business travel is in my future.

It's with that fortune cookie that I got. There you go. Oh, yes. Yeah, I know. But it's also about as you hire more people, I think talent density is just so critical. And that is how we built the company so far. And we want to make sure that we keep talent density high, that in fact, if anything, our bar should be higher for the next stage.

And so that is going to be critical for the company. I also think it's gonna be really important for us to, for me personally, but I mean, you know, our leaders and the engineers who are working on these new things that we talked about, they're all great. But I personally feel a need to stay informed and close to these things at a high level. And so part of my job would be

to be to kind of calibrate my level of involvement in these things in these large investments. And I have previously been very involved, but I'm not sure that that is not the right thing to do going forward as well. And so I think it's going to be thinking hard about that. It's going to be talking to other founders and CEOs who have gone through these stages, that's always incredibly helpful. And yeah, just getting better at my job as CEO. So nothing changes, right? Like it's all the same.

This is just a milestone. And my goal is to continue to do what our customers ask of us and want and need. So continue staying close to the customers, continue to stay close to all the new people we hire because I don't wanna become this sort of, oh, he's the CEO and you'd never get to talk to him. That's not who I am. I still interview every person we make an offer to.

Is that right? And- At what point, early or late usually? I interview them when we're very close to making an offer because otherwise I would not get anything done. Okay. Yeah, and I don't know how long I'll continue. Is that your own personal role?

Like, where did that- Yes, it is. Where did that, okay. Yeah, I love doing it because I want to, it's very personal to me who we bring onto this journey. And so I want to talk to them before we bring them on. And I don't go and tell the team to not hire them. There has been maybe a couple of times

when I have done that, when I have done that, but I rarely do it, almost never. But I want to make sure that I know their name before they join the company, that I put a face to the name so when I see them next time, it's not like, hey, who are you? Where did you come from? It's not going to be possible forever, of course,

but I love doing it. And I also doing it. And I also think it helps them to see, again, going back to my role as CEO to align the company around where we're going, for them to hear that from me. And I actually do think it helps us in closing the best candidates. Yeah, for sure. I want to dig in a little bit because I'm looking at your, at least what I can tell is your org chart based on your

your About page. I don't see a co. Oh, I don't see a CTO those two particular roles in particular I do see VPs of people product finance engineering and maybe a VP of engineering is the CTO acting role, but they're not literally the CTO. And if you're because sometimes to be a great leader, you have to have great leadership beneath you. And those two roles like a CEO is such a critical role to a well producing CEO. And I would even say the CTO as well.

Do you act in those roles? Essentially, is that do you sort of bridge the gap between? What seems to be missing based on just titles? That's a great question. So I Don't know if we need Us either of those roles right now. I'm not Acting CEO for us worth and I am also not necessarily I'm not acting COO for Osworth. And I am also not necessarily playing CTO. And I'll tell you, the reasons are different in each case.

For the COO role, I think typically what ends up happening is marketing, finance, sales, everything that is not EPD, engineering product and design, they end up reporting to a COO. And I am very comfortable and would actually prefer to have the leaders of these functions report directly to me because I want to be that level of involved in what's going on.

And I don't want to create yet another layer between me and the leader of marketing and the leader of sales and the leader of finance. So I enjoy that level of working closely with them. I also think it might not always be true, but I also think that we can attract more senior executives that way because they're reporting directly to the CEO and they're part of the day-to-day executive decision making. And I haven't felt the need for it. So, yes, I'm hiring a marketing leader right now, but then they'll report directly to me and that's totally fine. And I don't need a CEO to do that. So that's how I think about the COO role. I'm not sure it'll be necessary at any point in our future.

There are a lot of very successful companies that don't actually have COOs. So there are different models for running these things. On the CTO side, I think it does come down to the kind of engineers you hire. Obviously, you're VP of engineering, of course, but we have generally hired engineers who have very strong points of view on what technology can do and what else is out there in the market and where technology is going.

And it's a team effort for us. So even our VP of product is very involved in the technology choices that our customers are making and understanding those choices. It's fundamentally a very, very, very highly technical company. Our VP of product was previously an engineer at Heroku back in the day, a very long time ago. And then she was at Slack and she was at Figma and then she was at Webflow and then she joined Render.

And so she's, you know, but then our VP of engineering was previously the VP of product engineering at Discord. And so we had these people around the table and I'm an engineer by trade. So like we don't see that CTO shaped hole yet. And again, there are a lot of companies at our stage especially that don't have CTOs. And so we're okay. I don't want to like hire people for the sake of it,

just to fill out an org chart, right? And I actually think, I mean, the VP title is whatever, like they could have the CXO title also. So it's just a thing. And so that's how I think about both of those roles. Gotcha. I imagine as you keep reinventing, like you had said, you want to maintain, you're calibrating, to use your words back at you, you're calibrating

your involvement in particulars, you know, in particular innovations, products, etc. and how you hire and whatnot. I think that's so cool that you meet with everyone that you're going to give an offer to. I think that's it's it's grounding is what it is right? It's it's it's grounding for you one to see every person who's coming into the organization then two you know removing that stigma of your potential level of importance to the organization which is crucial obviously but your your accessibility to to folks. I think it's probably so rewarding for them

and for you to know that, okay, Anurag gave me time, sat down and just talked with me about what my role is, where this company is gonna go, and how thankful he is to have me as a part of this. And just show that, I imagine that's what you do, right? To show your gratitude, you know? Yeah, yeah, and people have lots of choices. Great people have lots of choices.

And when you wanna hire great people, it's more them doing you a favor than anything else, right? That's right. Yeah, and so it just becomes really important for me to know that I can talk to them directly and that we can have a one-on-one conversation that feels genuine, natural, and honest. And again, we want to hire people who are low ego, no drama, want to do great work, are ambitious, but not like blindly so, and are excited about what we're doing, are passionate about what we're doing here. And all of that shines through in these conversations. And sometimes I have to explain to them what we do,

which is also something that, again, keeps me fresh, right? Like, what do we do? I get asked that question several times a week. Tell them, listen to this podcast. Yeah, exactly. Right? Exactly. So-

For the next little bit, this is your introduction to who we are is listen to this podcast. Should I? Do you want me to talk about it? Sorry. I was joking, but I think it's true because- Oh, you're joking. Okay. Yeah, yeah. No, no, no. I was joking, but being serious at the same time. I don't know how you describe that. Actually, I'll give you the frame of reference because a while back I had interviewed sits a brandage who's famous for founding GitLab, you know, and he and his team loved the way I conducted the conversation. I wouldn't call an interview. Obviously I'm asking you questions, but it's more conversation, you know, I'm not following, you know, and it was on there.

They had their open documentation for when they hired new people. And it was essentially, if you wanted to get to know Sid, you would listen to or pay attention to these pieces of content slash media that was out there. And I had gotten serious praise from within GitLab about my ability to conduct conversations with Sid over the years. And so that's kind of where that joke,

but searingness came from was that it was sort of inside our baseball. That's why I explained it. Because, and honestly, it was an honor to be told that. Cause like, they didn't even have to tell me that. I don't know who links up my stuff or links up our stuff and shares it and says, this is a reference point. But I think, you know, we encapsulated, you know,

your focus on application developers. So I think clarity would be just simply like, wow, render's focus is on app developers, and not DevOps, not this particular discipline, it's application developers, people who are building and shipping the actual application. And if it doesn't serve them, is it truly something we should be doing?

So I think that's why I say that is joke, but seriousness. No, I mean, obviously, I've really enjoyed the conversation so far. And I think you're at the top of your game. You know what you're doing. So I'm not surprised. I try. You know, it's just talking. You know, it's just talking.

Yeah. Yeah. I loved, I was listening to the chat you had with Kurt and at Fly and you were like, just dude, how are you? And yeah. Yeah, man. How's life? I almost pulled that part out.

No, I thought it was great. I'm glad that you left it in. Yeah, I was, well, cause like it was, to give some context to those who might be catching up, we'll link it up in the show and stuff, of course, but I asked Kurt how his life is and he recently went through a divorce that sort of changed his entire life. And he was happy to share that. And so in the moment, I was like, you know, in my brain, I'm thinking, how deep should we go here? Because like, this is

a deviation from the topic, obviously, like we've been talking about reinventing the cloud, you know, this new public cloud kind of idea. And now here we are talking about divorce and I don't want to get melodramatic and get sad, but I also want to examine this because I feel like. Part of what we do here at ChangeLog is just is peel back the layers of the realness of what is what. Why did you not go and sip my ties on the beach? Why did you go back to work? Why do you care so deeply about interviewing

or sitting down with every person who comes in? Why are you so passionate about application developers? And it's beyond the technology, it's beyond even your drive as a human being. It's like, what makes you tick? You know, that shared decision between you and your wife to say, you know what, let's do this. And it's not just you go do you know, that shared decision between you and your wife to say, you know what, let's do this. And it's not just you go do the work,

it's us make the choice of allowing one part of the whole to go and do one more, maybe more adventures, you know, one big adventure, one more big adventure. And I think that's what it's all about really. You can't just simply say, tell me why you think Kubernetes sucks. Let's talk about that for 40 minutes, right? Or it doesn't suck. Or let's just say like tell me why you think Kubernetes sucks. Yeah. Let's talk about that for 40 minutes. Right.

Or it doesn't suck. Or let's just say like, why do you think it sucks for application developers? It doesn't suck for DevOps. Yeah. I got a great friend of mine who is, who is a DevOps. I would just say, you know, Borland genius. He loves Kubernetes. I mean, it's great for a lot of reasons for, yeah, but that's because he's a

DevOps engineer, he's a DevOps engineer. He's not an application developer. Application developers don't really care that much about orchestration. They care about applications and production. So yeah, I appreciate that. I appreciate that. And I think that's interesting that you bring up Kubernetes

because another way to think about render is often Kubernetes, the good part. OK. Yeah, because you get the things that you bring up Kubernetes because another way to think about render is often Kubernetes, the good parts. Okay. Yeah. Because you get the things that... The small book versus the big book. Yeah, exactly. The stuff that you actually want from Kubernetes without ever having to learn Kubernetes. But I think Kubernetes actually is a great piece of technology, obviously massive ecosystems, so much value that has been created, also just unbearable complexity. And there's all these vendors upon vendors upon vendors that I'm sure, I don't know if you've seen this with the CNCF landscape chart, that yeah,

it's massive, it keeps growing every year. And it will, I mean, that's just, I mean, it's entropy. That's how it works for that. I mean, it makes sense to do so. Yeah, it makes sense for a certain market. But actually going back to your interview with Kurt, I'm glad that you left it in and also that Kurt was open to talking about it

because I like Kurt. Yeah, Kurt and I have chatted in the past. I like him. I think he's a great human being. And I think, again, we're serving different parts of sort of the same market. But I think it's, again, like I say, it's big enough for, that's a good thing about the cloud. It's like very big. So people can do their own thing and still be successful. You know, knowing what I know about both of you as individuals and then also Render and Fly, I would say you're very similar,

but also very, very different. Like very, very different. Like when I play with Render versus Fly, you're solving similar problems for the same developer type, application developers, but you're doing them in uniquely different ways. And that's what the market needs because where there's push, there's pull.

And it's not a choice of fly versus render or either or. I think there's really just, it comes down to the kind of developer you are even. Like there's still fractures and fragments within the application developer sliver of the market, right, like you're gonna have some who care more deeply about unique things they can abstract away or up into the fly platform from Linux, you know,

and all the different things they're doing there. I think there's so much room in the market that's why I'm never we've never been a We've tried to resist I mean because sometimes you do pick a favorite, but we've really tried to resist picking a favorite, you know and That's hard. It's it's really hard when you have that responsibility because you know when you kind of a favorite say well You know what? I do have a favorite. Can I tell you my favorite? You know, maybe I can, maybe I can't, but we really try to keep it up in mind

because similar to the, to, you know, your ethos, our ethos is that we want to share what could be and should be given attention to, to, to developers across the globe. So it's not like, Oh, this exists and nothing else exists, so use only that. It's more like, if you're a developer, whatever your challenge is, here's the menu, so to speak, of what you can use to solve your problems.

Because at the end of the day, in our Zulip chat room, which is not Slack anymore, we use Zulip now, not Slack. I don't know if you know about Zulip. Oh, I know the founder, yeah. Fantastic, I mean I always, I come to that conversation sometimes, I'm like, do you know what Zulip is? Okay, because if you don't, let me tell you, but if not, now you know.

But in our Zulip, we're talking to individuals. You know, we're talking to developers. And we have friends and loyal fans and listeners over many, many, many years. You know, and it's, we're here to serve them, to showcase what's cool, what's important, what's changing, what's not, and to give that option to them and not pick favorites really. That's where we're at with that. That's awesome.

I'm pretty excited to have you on the show. I'm pretty excited about this new race for you. I'm excited for this legitimacy, you know, that I don't think you necessarily need it, but obviously a new label, Serious C, is going to change some people's minds, so to speak. Yeah, I remember back in, I think it was 2020, we emailed some folks who were on Heroku, and we were like, hey, you should maybe consider render. And one of them was like, dude, I'm not going to switch over to this startup.

I'm just gonna- They were honest with you, yeah. Yeah, he was pretty honest with me, which I appreciated. And I think it's true, like I wouldn't do it if I were in with you. Yeah. Yeah, he was pretty honest with me, which I appreciated. And I think it's true. I wouldn't do it if I were in their position. I was like, I don't know if Render is going to be around. They're just like a CSA company or whatever.

And they don't have, and back then we also didn't have all the features that we do. And that's always going to be true. Like we're always going to have fewer features today than we will two years from now, or even a year from now, or even a month from now. But I think back then we were missing more core things. And we've basically built out all the core stuff now,

except as three. We'll go build that. But coming up, I don't know if I think it's always it's here's the other thing about figuring out what to build and what not to build. The way we think about product is that a no is temporary and a yes is forever. And you can keep saying no to stuff. But as soon as you launch something, now you're stuck with it. As soon as you launch something that people are using. Yeah, you're stuck with it. You soon as you launch something that people are using, yeah, you're stuck with it.

You have to support it. You have to figure out how to deal with pricing. You have to make sure it works with the rest of your stack, your API surface area, your infrastructure as code, your whatever, your SDKs. You just have to keep doing that work over and over again as soon as you build something. And so we're very careful about what we take on, but I think one of the things that we're

going to be able to do this year is take on more interesting stuff that I talked about and even more than that. And that's what I'm excited about, just allowing people to use render in new ways and also continuing to help people scale. You know, our managed Postgres has come a long way. So this was another thing that we were pretty far behind Heroku on, and now we're actually better than them. And they're switching over to Aurora and saying,

oh, we're not going to build our own Postgres anymore. It's just like, all right, well, that's your call. And I think for us, it goes back to the experience, right? So if you try to build a wrapper over Aurora, then you're a wrapper over Aurora and you have to deal with their vagaries. And it's not even like, Aurora is not Postgres, Postgres. It's Postgres compatible,

but there will be stuff in your function code or your triggers that just won't work the same way. And all the documentation online is for Postgres. It's not necessarily for how Postgres on Aurora works. And so I think the other thing that we've been lucky about is Heroku has made our job easier. It has helped drive people into our arms. And that was the other thing that happened when they killed their free tier back in 2022.

That was when a lot of people first discovered render. And it wasn't that our free tier took, not just that our free tier took off after that. It was also that our revenue took off after Heroku killed off their free tier, which is just, you know, a self goal, I'd say. Mm-hmm. Right place, right time. I think it's prudent for you to showcase that, you know,

your demeanor might be, or your point might be, we're the better new Heroku. Well, but we're not, that's the other thing. Because I don't think about render as being a better Heroku or even a better AWS. I think when you think about a company as like a better X, then it constrains the possibilities of what's possible. And so, you know, early back in the day,

Stripe benefited from PayPal's mistakes. For sure. And from the mistakes of everyone else. And so I think in some ways the story is similar. But I think with us, people come to us, people who've used Heroku before and who we know are using Heroku look at us and they want details on how render might be better. And so maybe that's what we were trying here. But surprisingly, I was surprised by this. So when we ask people where they're moving from,

and they can choose to not tell us, but if they do tell us, when we look at where people are moving from, more people move to render from AWS than from Heroku. Yeah, and many more people move to us from AWS than from Heroku, which to me says we're doing something right, because Render is not the next Heroku. Render is actually a replacement for people

for both Heroku and AWS. And for a certain category of people, application engineers, like you were saying, like I was saying, who want to get started quickly, but also scale and have not have to worry about whether they need to spin up Kubernetes. That's who render is great for. In the future, there will still be people who are doing DevOps and there will still be people who are running stuff on bare metal as there are today.

In fact, there are people who've gone back to bare metal as we all know. We all know that, yeah. Yeah. We didn't talk about that, but yes, for sure. Exactly. Anti-cloud. Yeah, there's this whole thing.

I mean, it's a bit, I think DHH does a great job marketing it. It's not clear to me if the big move is happening because the clouds keep making more money every quarter. Well, I think just what you said before, which is there's room for that too. Yeah, absolutely. There's room for bare metal

and there's room for those who are like, you know what, it's not so much anti-cloud, it's more like you're a build versus buy. We could, so we should. All right? Yeah. You were able to, you have the talent, you had the control, it benefited you to have the control, so you did.

Same thing here, I think it's less, but I think David Hamar Hansen's persona is counter-cultural. It is provocative in a way, in a lot of ways. So I think it's natural for his opinions because he holds his opinions very hard He's hard in his opinions and he's very articulate and clear which I love about him I mean whether you like his opinions or not, that's a fact I love about him, which is no matter if I like his opinion or not. He will have clarity and

Conviction behind his opinion. Yeah, he's have clarity and conviction behind his opinion. Yeah, he's incredibly smart. Right. And so I think just the saying there's room for those who are like, you know what? I can put this server rack in co-location and we can do this and all this different stuff. And that might serve them and their purpose for them

and for whatever. But I think you're building for a different application developer that thrives in speed and autonomy, not in standing up servers and managing servers, whether it's easy or not. Yeah, and we use, behind the scenes, we use both AWS and GCP, and that doesn't mean that that is what we're

always going to use. In fact, again, this year, that might change. And we're not going to- Some bare metal? So we're not going to get rid of AWS or GCP. And we're not going to ask customers who are on AWS or GCP to move. In fact, we'll still continue to add people there.

But I think there is now it's incumbent on us as a business to also look at lower cost compute, whether that's bare metal, or, you know, some dedicated hosting in Hezner. I've heard a lot of scary stories about Hezner servers going down. scary stories about heads and our servers going down. But a lot of people use them and they're cheap if nothing else. So I think we need to explore our options because it's not clear to me that AWS is the best long-term partner for us.

And I do think that AWS is a better partner than GCP though. And we can talk about that some other time. And I do think that AWS is a better partner than GCP though. And we can talk about that some other time. Yeah. Well, I think the way to get there is really what do application developers want? Yes, that is the mantra. If they want a diversity of choice, well then you're gonna offer them a diversity of choice.

If they want a diversity of choice because of cost, well then you're gonna offer a diversity of choice because of cost. Exactly. And if that doesn't make sense then you won't do it because if your mission is to serve app developers then you're gonna figure out what the 80% of the 100% of the market that's an app developer wants and render is, I assume, attempting to attempting to solve for 80% of the challenge that app developers have. That's not Pareto's principle, right? 80-20.

I think people on render will always, they should always be able to use specialized compute or specialized services and other cloud providers, right? And so we actually, if you have some compute running on AWS, then Render can set a private link from Render to AWS. So you can always connect to your services on AWS securely and privately. And a lot of our customers really appreciate that. Yeah, for sure.

Well, I'm excited for you. I'm excited that we've got you on the show, so we can check that box. I'm excited that, you know, that potentially this could become the new, if you wanna learn about Honorog and what Render is doing in the next year or so, this could be a new link for you to share with folks. Oh, for sure.

What else is left? What else can we share in terms of anything we haven't covered that you want to? No, I think this was pretty far ranging. Like I enjoy the conversation. There's a lot of switching between topics and things, but it was that sort of conversation is. It's not a straight line. We'll get you back on. We'll make you a staple every once a year, let's say.

Something like that. Let's get you back on. I would love that. I'm a fan of what you've done. I'm a fan of innovating for developers. And I think if that's what you're doing, which I think you are, I'm happy you're doing that. And stoked. Stoked for render.

Yeah. Thank you Adam, really appreciate it. All right, Anurag, thank you. Well, the cloud is big and there's lots of room up there. I'm excited about having another platform as a service to call upon, to lean upon to have application developers to be empowered to create and develop the software and to deliver that software themselves.

There's a bit of magic that happens when a developer can understand how the code they write gets delivered to and runs in production. I love that. So if you haven't yet, go to render.com, check them out, see what they're doing. There you go. And of course, a big thank you to our friends over at Retool, our friends over at Sentry,

and yes, our friends over at Temporal. Retool.com, Sentry.io, and Temporal.io. They love us, they sponsor us, and you should check them out. And yes, there's a bonus on today's show. So that means our plus plus subscribers are getting a treat. I love that. If this is new to you, changelaw.com slash plus plus. It's better. Yes, it is better.

It's better because you get to drop the ads. You get to directly support us. You get to go a little closer to that cool change log bare metal. And of course, bonus content like today. Once again, changelog.com slash plus plus. It's better. And of course, to the beat freak in residence, brake, master, cylinder, bringing those beats. So bang it. Okay.

This show's done. We'll see moment on stage. Did you get the check on stage? Was it you plus three what science was the team? Were you excited and giddy did you expect to win? You know take me back literally to the hairs standing up on your arms winning moment yeah, so when they announced the results they do it in terms of when they announced the results, they do it in terms of three to one. So they pick three winner, well, the number one, two and three. And so they announced number three. And then

this was, I think 10 companies get to the final stage. And then they announced number two. And when they announced number two, I actually knew we were going to win.