# Render CEO on AI Agents, GEO, and SaaS Future

**Podcast:** alphalist.CTO Podcast - For CTOs and Technical Leaders
**Published:** 2026-06-18

## Transcript

Hello friends, this is the Alphalist podcast.
I am your host, Tobi.
The goal of the Alphalist podcast is to empower CTOs with the info and insight they need to make the best decisions for their company.
We do this by hosting top thought leaders and picking their brains for insights into technical leadership and tech trends.
If you believe in the power of accumulated knowledge to accelerate growth, make sure to subscribe to this podcast.
Plus, if you're an experienced CTO, you will love the discussion happening in our Slack space where over 600 CTOs are sharing insights or visit one of our events.
Just go to alphalist.com to apply.
Welcome to the Alphalist podcast.
My guest today runs one of the places a huge chunk of the internet quietly deploys onto.
And lately, a lot of what's getting deployed isn't a website.
It's an agent.
He's the founder and CEO of Render.com.
Welcome, Anurag Gohl.
Thank you, Joey.
Thank you for having me.
Thanks for being here.
Your story is kind of fascinating.
I think you first worked for Stripe and then throughout the years, I think navigated through that, let's say, hyper growth phase of SaaS, of B2B SaaS, and now ended up really being AI first and a tool for the AI first world.
On the way there...
You raised, I think, almost 300 million.
Is that correct?
260 plus, yeah.
260 plus from like crazy popular VCs like Bessemer, right?
Bessemer General Catalyst.
Yeah.
That's quite impressive.
Thank you.
Before you tell us more about what you're doing and why, maybe we start a little earlier in your youth, hopefully, or childhood.
I don't know.
when you started off really liking computers.
So when did computers felt like something you like and you're into and why?
Oh, that goes way back.
I think the real answer to this question is actually when I started building my own projects.
When I was a child, I wasn't coding as much.
Most of my real coding experience came from college and then eventually being a software engineer after college.
And the true joy of it came from just building things and putting it out in the world for other people.
Building, for example, the very first e-book search engine that collected e-books from Amazon and Barnes & Noble and a bunch of other places and put all of them in the same interface.
This was back when Amazon was not as dominant in e-books as it is today.
And there were a bunch of other smaller e-book sites and a lot of them had free e-books.
And so I remember I really enjoyed putting that together and putting it online and then built other things.
There was a video game.
rental platform, if you will.
And that was actually the first project for which I needed payments.
And that's how I got involved with what was called slash dev slash payments in 2010.
And or dev payments is actually what it was called, but it was written with the Unix slash dev slash payments.
I accepted my first payment for this video game rental thing, which is not a great idea, by the way.
I just did it because a friend came to me with the idea and I was kind of bored and I wanted to build something.
And I got to know the team a little bit better as I was accepting payments using their product.
I was super early.
And then that's the team that changed their name in March 2011 to Stripe.
And through that back and forth, I ended up just joining Stripe in July of 2011 as the fifth engineer, where I later became the head of risk.
Looking back, what is the key ingredient you took as someone who worked very early in Stripe and who learned a lot?
What did you take for your...
your Render journey with you?
And do you still apply today or not?
Yeah, a lot.
A lot of it came down to caring very deeply about the end user experience and going the extra mile for that.
And that's something that we did from the beginning at Render, focused on throughout our journey.
And we're still continuing to improve.
the experience for developers.
But these days, you also have to think about the experience for agents.
And that's just a new end user.
And we were, again, going down and figuring out how we can make the experience for agents the best possible.
And the other piece is just the notion of talent density, really hiring incredibly ambitious, smart.
but also kind people, people you want to be around, people you respect, and really, ideally, the best people in the world for what you're trying to do.
And not being afraid to wait to hire that person instead of just trying to fill seats.
I think those two things are probably the top two for me from Stripe.
So not filling a chair with a warm body, essentially, right?
And how did you really raise the bar in hiring?
Like, what was your, is there like a secret ingredient?
I mean, apart from not being impatient, is it like the interview process that's really tough?
Like an aspiration that you kind of spread?
Or what, like, how do you change?
How do you do it differently?
For us, a lot of it has to do, especially these days, with what they've done in the past, because that's often the best predictor for how they will do here.
And we try really hard to understand that.
Interviews by themselves are actually fairly imperfect signals.
You can get some signal and for certain kinds of roles, you can get better signal than not.
For example, for a sales role, especially if I'm hiring, I recently hired a leader for our sales function.
And I've never been a sales leader myself.
I have been a founder who has sold render to other people, our customers.
But really it came down to digging really deep into what they had done, whether they had worked at really great companies so they know what greatness even looks like.
Sometimes, you know, people who themselves could be amazing have never seen what amazing or great standards are.
So you only see that when you get a chance to work at really good companies because you see other people who have seen that before.
And we learn a lot by looking at how other people do things.
I think that's often a big requirement for us too, when we hire people, especially these days, again, like have they spent time understanding what great performance is?
And the later they are in their career, the more strict that requirement is.
How did that go for you and sales?
Like in a field where you...
I also assume you're a PLG company, right?
We are.
We are actually, yeah.
So 90, I think somewhere between 90 and 95% of our revenue comes from self-serve.
There's no sales involved.
But we're also now seeing larger companies come to us.
And often when you're a company at a certain size, you just want to talk to someone.
We're seeing some opportunities in the market where we can proactively go sell some of our products to some larger companies.
So both of those things make it important, really important for us to think about sales as a strategic growth lever.
And so the person we actually hired, his name is Sam Taylor.
He comes from a PLG to sales background.
He led sales at Loom, which was, again, very much self-serve.
And then there was an enterprise component.
He was also at Dropbox very early on.
And so, yeah, so there's a, you've seen what great looks like.
You've seen PLG2 sales and he's just a really great sharp guy.
And so, and the other thing for executive hiring, and I know this is a CTO podcast, but.
executive hiring is just always kind of on my mind.
I am hiring a leader for our product team right now after our previous one left and we were looking for someone for the next stage.
And exec hiring is all about really digging into what they've done before, how they've led teams, what kind of people they've hired.
And that's also something that I learned from Stripe in terms of Just what kind of signals to look for, who does well, who doesn't.
Because executives, good ones, and even some not so good ones, can often show up quite well in interviews.
It's not like an engineering interview, right?
With engineering, there are hard truths.
With execs, it's not always clear that what they're saying they did is actually what happened.
And so then you need to go deeper into...
Building as complete a picture as possible by talking to many people they've worked with.
And I've heard this from other leaders as well, other CEOs and founders.
Really, the more you can learn from the people they worked with, the more people you can talk to, the better.
So you can build a really accurate picture, not just of what they're like working with the CEO, but also what they're like working with their peers, what they're like building a team.
Does their team really respect them?
Is the team they built inspired by them?
Can they really push the team to do better?
That's much more important than, for example, how they interact with the CEO.
That makes sense.
To what extent do you include the team reported to that person or the former leader of that person in the process?
Do you also do reference calls or stuff like that to kind of validate?
Yeah.
Yeah.
do reference calls with not just the person they were reporting to, which is typically the CEO, but also the other executives that they worked with and then people they managed.
For me, this is always also a bit of a Trojan horse into the other company you're talking to, right?
Like, I don't know, like you talking to the CEO directly of the former company.
Also, like, it's...
in a way, a push for your own network.
So it's something I really value, right?
That's really, really important for me because you kind of end up being smarter and having one additional contact that you didn't have before, right?
Absolutely.
It's also a bit of a growth hack for yourself, right?
I see.
But maybe like, Before we dig deeper there and on the whole trajectory you're recently heading, can you tell me why you actually started Render?
I mean, what was that pivotal moment when, I mean, you were ahead of risk so that potentially you wanted to deploy to a safe place?
I don't know.
No, no.
Or you just saw like how the developer mode works and like, tell me more.
Yeah, so at Stripe, Very early on, you know, about 20% of our engineering team was just focused on managing AWS.
And as the engineering team grew, that fraction remained the same.
And it wasn't that the team managing AWS was doing anything particularly exciting.
They were just, you know, writing scripts that really...
were very AWS specific.
They were building out some sort of internal interface that the rest of the platform, the rest of the application teams could use.
A lot of that work was automatable.
And a lot of it was repetitive and error prone.
Because when you're writing all this configuration, then you're bound to make a mistake.
So that's something that I saw at Stripe.
And then after I left Stripe, I didn't know when I left that I was going to start Render.
I really just wanted to solve a big, important problem.
And I wanted to take my time to discover what that problem would be.
And I went through a series of problems that I then built applications as product solutions for.
And as I was building them, it continued to become even more apparent to me that it was so much easier to build an application and it remained really hard to productionize it, to scale it, to operate it.
And through all that knowledge that I had gained, it just made sense to me to automate as much of the DevOps work as possible and give people a modern platform.
that is still flexible enough for companies to do more complicated things as opposed to just a simple web app or a 12-factor app back in the day, as Heroku used to call it.
And so Render has always had the ability to store things on a disk.
Render has always had private networking.
We don't really subscribe to this 12-factor notion, though you can build your apps that way.
I've always believed that the way applications are built changes every few years.
And we went from Ruby on Rails in 2005 to containers and this separation of the front end and the back end and microservices in 2015 or so.
And these days were...
looking at AI generating all these services.
And even though the patterns might not have changed, the way we're building the apps has changed completely.
The number of applications being developed has changed completely.
But actually with agents, the type of applications is changing because agents are long-running, stateful applications that call a lot of tools and there's a lot of IO and they're not serving web apps necessarily.
And so this is a very new kind of application that a lot of platforms don't support well.
So Render's goal has always been to build the platform that can support you as an application team, application development team, no matter what you're building.
Which is why, you know, as other providers have often called themselves the AI cloud, everyone's trying to call themselves the AI cloud.
These days, it's the case.
Yeah, we are an application cloud.
And AI applications are just another type of application that you build, software application that you build.
And so just like Render works really well for your traditional application stack, which is your web stack, your database, your background workers, your caches, Redis, and so on.
Render also works really well.
for the new way to build applications.
For example, with things like workflows, where you have to orchestrate a series of tasks and each task could fail and you have to have retries and you need observability across all of that.
Or things like sandboxes, which is very ephemeral compute that needs to be run in an isolated manner.
So we're finding these new ways in which our customers are building applications.
in addition to the traditional stack.
So Render is really the one place where they're both hosting the traditional part of their applications because every application still has a traditional side of things.
Everyone still has a web app of some sort, a database.
But then they also are now building these AI native patterns like agents.
And how do we help them do both in the same place as what we think about these days?
Okay.
And I guess, I mean, you come from Stripe.
So Stripe is also a Rails shop, right?
So, or mostly a Rails shop, or used to be, at least back in the days.
Stripe was Ruby, never Rails.
Only Ruby, never Rails.
Okay, that I didn't know.
Okay, but I guess you're Ruby-ist yourself, or like, are you?
No.
So Render is largely built in Go, on the backend.
In Go, okay.
Yeah.
Yeah, and our front end is, you know, TypeScript and the standard front end.
So I guess that's also like you went out and thought, okay, what is the most modern stack that kind of is like really also attractive for developers and took that or?
Well, Go is particularly great for building infrastructure primitives.
And the reason for that is just the wide.
community-level software available for Go.
And Go in it by itself, the language comes with a built-in web server, a built-in reverse proxy, which I don't know, many languages that come with a built-in reverse proxy.
And then some of the projects that have defined modern infrastructure, Docker, Kubernetes, others, like a lot of them have Go code and they're written in Go.
And so, It just made sense when I started the company to use Go as the core primitive, as opposed to, say, Rust.
Because with Rust, the infrastructure components around Rust were just not very mature then.
And so we largely found it sufficient for our tasks.
And we serve hundreds of...
billions of web requests every month with our Go proxy and it runs just fine.
Yeah, I also have very good experience.
Like also recently in the agentic coding world, right?
Like just taking Go as a language which is compiled and runs everywhere is phenomenal.
And also the required knowledge of the language that is like close to non-existing if you just want to get started and you're like a vetted engineer.
That's really fascinating to me.
Like just writing like a CLI tool quickly or like even a richer UI on the terminal, like a TUI is really for me phenomenal.
I use that a lot.
But I was asking more because like you're building a dev tool kind of from like the Stripe angle back in the days.
And I just thought like you were like kind of looking at Heroku and seeing that as a thing which is a journey which is doomed to end at a certain point and then saw the chance.
Was that also like partly the case or?
Well, to be completely honest, I wasn't looking at Heroku when I started Render.
Because I think in many ways, Heroku had already lost the battle for mindshare for the most forward-looking companies back then.
No one I knew was using Heroku.
And these are the most tech-forward startups.
And there were a bunch of reasons for that.
I think Heroku had become quite stale and it didn't have a lot of really basic features.
So it wasn't even part of the conversation.
But after Render took off, we saw a lot of people migrating from Heroku to Render.
And I think fundamentally, the problems that Render solved were very similar to the problems that people are trying to solve with Heroku.
But they found that Render was actually much more modern.
It was more cost-effective.
They could do a lot more on Render.
They didn't need to migrate to AWS.
They could stay on render and grow, even as their applications became more complex.
So I guess then the news that Heroku is in maintenance mode wasn't like super new for you or is no longer really maintained, but like just a little yes moment.
And you won the customers anyway already, right?
It was, no, we're actually surprisingly getting...
a lot of customers who are still on Heroku.
And so this year, our sales pipeline has kind of exploded because all these people on Heroku now realize that the end is near.
And Salesforce not offering new enterprise contracts means that at some point, they'll stop renewing enterprise contracts.
And I knew that the end was near when Heroku switched off their free tier.
Because you generally don't switch off a free tier that is so widely adopted if you want to continue to grow the product.
And so that signal to me was very clear about like, no, we don't actually care about this product, Salesforce said.
And they've tried a bunch of things since then.
Not a lot has panned out.
They tried to build a Kubernetes-based version.
I don't know if that's...
happening still.
They've gone through a bunch of CEOs.
So we still have people coming from Heroku to us, but we're not really focused on what, you know, as we think about what's next, we're not focused on the old school Heroku stacks.
We're much more focused on what people are building these days with new applications.
And our platform is sufficient, more than sufficient.
for the old school Heroku stacks that are moving to us.
So we don't have to build anything new necessarily for them.
There are some minor things that we can do, but most of our excitement and new product development is really focused on what AI native applications need and what agents need.
Understood.
And tell me more about your moment when you were first discovered, like, hey, This agentic world is really our thing.
Before we talk about concrete agents and how to host agents on your platform, there's, I think, also a fundamental shift when people started using cloud and codecs and needed some sort of an angle to deploy to, right?
Like a cloud to deploy to.
And you were just there?
Like, were you prepared for that already?
Or did you see that chance and then said, like, we're going all in?
Or what was that?
How was that moment?
Yeah.
So at the beginning of 2025 is when we first saw just a huge increase in adoption for Render.
And a lot of that came from...
ChatGPT and Claude and others recommending to users, to developers, that they should host these apps on render as opposed to AWS.
And I think people, a lot of people then realize, oh, I don't need AWS if this is what I want to do.
But I don't think a ton of people were building.
agents back then, there were certainly startups, like YC startups that were building these things, and many of them were on render.
And so even back then, it was clear to us that some of these teams would need a way to, for these teams that were building agents, for example, or any kind of AI native app.
One of the big problems they were running into was they would call out to the LLMs and the calls would fail.
They would need to retry the calls multiple times.
And then it would lead, you know, then if that step succeeds eventually, then you need to go to the next step, which processes some data and sends it back to these.
So we actually identified early in 2025 that we needed to solve this problem of asynchronous task execution, especially a series of tasks that depend on each other where the user needs reliability, durability, and the need of observability.
Right.
Yeah, exactly.
And so we started building workflows largely as a response to what we were seeing with our customers.
So our customers were using background workers for this.
And background workers are great when you have tasks that are discrete, unlikely to fail, and very similar to each other.
But when you, let's say, are processing documents, the LLM could fail.
Each document could have a different size completely.
And so you would need different levels of compute for each task.
You could end up making lots of calls in the series of things you need to do to process the document, and each call depends on the previous one.
So doing all of that with background workers is very hard.
You have to write a lot of code, effectively building out kind of your own workflows product, which a lot of teams realize they just don't want to do because then they're just in the middle of maintaining all of this.
And so we launched vendor workflows.
Earlier this year, it should be in general availability within a month or so.
But it's been really successful, even in early access, because it's a core primitive of how people are building apps in this new world, where they're using LLMs more and more.
So we started seeing this earlier in 2025.
And then we also started seeing customers who were using Render for their core web stack and their database, the Postgres and Redis.
But then they were using someone else for their sandboxes.
They were using a completely different party for workflows, something else for their AI gateway, something else for a shared file system.
And it became, again, it became clear to us from talking to these customers that really they wanted everything to be on render.
They want everything to be in one place.
They really don't want to plug five different vendors into their stack because then you have to deal with five different places to observe.
You have to deal with five different bills.
You have to deal with the integrations between all of these things, the network costs.
of going across these things.
And then you have to deal with permissions and securing the five different things versus, you know, if everything is on render, then you can just define your permissions once and you're done.
So that also became really important to us to build out what we're internally calling this consolidated AI runtime, which includes...
all the primitives that customers need, that our application developers are building on Render, that they need to build really powerful AI-native apps and agents.
Do you think you're there already?
Or I still see that pattern of someone really deploying the front-end to Render or Versatile while having the back-end or the database, at least on Superbase or something similar.
That's still happening, right?
Yeah, so we're definitely at the point where you can deploy the front-end and the back-end and the database all on render.
But what we don't have yet is the AI components that I mentioned.
So we're very actively working on them.
So we're working on sandboxes.
And the goal is to have the first invite-only version out within a month.
We already have workflows which will also go into general availability soon.
We're also thinking hard about what agent context derivatives we can share with our customers, what kind of observability.
we can share with our customers when it comes to what agents are doing, because that remains a big pain point.
And then how do we help our users get a better sense of what's happening in these AI applications, not just what individual agents are doing, but also things like cost.
And then maybe adding resilience, both to workflows, but also resilience to these LLM provider calls, which are notoriously flaky by adding some sort of gateway and then securing these calls by making sure that your agents don't have access to your keys and that you have some sort of tokenization as part of the system.
Yeah, security has recently been a bit of a heavy wind in the scene.
How do you see that?
I mean, there recently was this, let's say, incident on Vercel and a few other things, like GitHub Parley was hacked, like a few internal repos.
Whenever you hear such a story, what are your thoughts?
These days, it's not a matter of if, it's a matter of when.
Because every...
provider, every open source library, every cloud.
We have seen enough breaches over the last few months to make me wonder if anyone can truly claim that they're safe.
I don't think anyone can.
And it's a bit of a...
And security often is, but it's definitely a bit of a, these days, a bit of a cat and mouse situation because people are coming up with more exploits using AI, but at the same time, you can protect better against those exploits using AI.
And we've all heard about Mythos and the security-focused programs that the foundation model providers have.
I still think that the biggest problems when it comes to securing your systems, the biggest set of problems remain under human control in that I think that it's much more likely for someone to take over or get credential access from an employee laptop than to try to escape out of a container.
And while they escape out of a container, things make headlines because there's a proof of concept around it.
What ends up usually happening is that credentials are stolen from an employee's laptop and then they're used to do other things.
That's what happened with Vercel.
Or still even committed to a repository, right?
Yeah, there you go.
Exactly.
So many of those examples as well, where like the human error is kind of there.
Human error, exactly.
And again, humans, I mean, look, you can't blame individuals.
I think that as a software industry, as an industry, and as people building these things, we have to take responsibility for minimizing the blast radius for human error.
And that's where we have to be.
better about what scope keys have and how long they have until they expire.
We'll have to build systems that are much more comfortable with short-lived keys that have fewer scopes.
And that's work that the industry will need to do much faster than it has been in the past.
And then we'll have to get really good at limiting the brass radius, assuming that the keys are going to get compromised.
So yeah, there's a lot of work.
You think of admin and forever is kind of over.
Yeah, absolutely.
Yeah.
We built a tool internally where if you need access, it doesn't matter who you are.
Like even if I need access to sensitive data that I need to ask.
for time-based access to it.
And we made it easy so you can ask in Slack and then someone has to approve it.
And so it's all logged.
You have time-based access.
And at least right now, your Slack identity is kind of mediating that.
And we're assuming that Slack is secure.
Let's hope that someone can't assume identity as me in Slack.
anytime soon.
Let's also hope that the free version of Slack will be around for a while, right?
I'm okay with paying for Slack if that means that we can continue to use it for company operations.
I just wanted to jump over from the Heroku mistake.
I know.
I'm always like shivering, like, let's hope Slack survives, right?
Like it's kind of critical infrastructure.
I think Slack will survive.
I don't think that, I don't think Slack is in danger, partly because I'd say that Slack is a product that has gained much broader acceptance than Heroku.
And so with Heroku, there was always AWS.
But with Slack, there's no alternative.
And so Salesforce is still making a lot of money from Slack, but they can also add AI features to Slack, which they have been doing and try to make more money from that.
And people would be much more angry with Salesforce if they took Slack away versus Heroku.
Yeah, you're right.
You're right.
And sorry for the detour.
Maybe coming a bit more to the concrete meat to the bone when it comes to agents and what people are actually building.
You sit on top of, I'd say, roughly 5 million developers on your platform?
Yeah, 6 million.
Now 6 million people on the platform.
Crazy.
And well, these days, I guess...
You don't know, like, is it people or agents, right?
So that's the first thing that is changing.
But like people are also building agents on your platform, building workflows on your platform, as you just mentioned.
And if you forget, render for a second, what are people actually building when they say agent?
What is, like, give me a real distribution, not like the Twitter version of it.
Like, what is happening on your platform?
I mean, I can talk more about what's happening in the industry in general, and it renders very representative of that.
So what we are seeing is there's a lot of companies, especially smaller ones, but certainly tech forward startups.
Eventually enterprises will start doing it, but right now it's mostly tech forward startups.
They're building internal agents.
And these internal agents do everything from, say, answer questions in Slack to process internal documents or handle service inquiries from people, IT inquiries from people, or, you know, look at data across the enterprise and share summaries or proactively alert people when something happens.
So a lot of folks are building these things internally because what they realize is that it's now possible to automate some of this.
And this was human work.
especially if you were a human doing it, sometimes it wasn't even possible to do all this work.
But now you can just let the agent run overnight and you can have multiple parallel agents and they'll do this.
And so people are using, they're actually using Claude and Codex to do coding adjacent work.
And that's pretty interesting.
But then when they build these internal agents, they also find that they can offer some of these things as products.
And so then they start thinking about how to expose this data externally or expose these agents externally as products.
And so often internal agents then become what a company is selling externally.
We're seeing more of that.
And obviously, we know what kind of external agents are doing.
really well.
There's a lot of like knowledge worker agents where you have something that's constantly processing a lot of data and either learning on it or helping you answer questions about it and then calling tool use in real time and getting better at answering questions by incorporating a bunch of tools.
There are also the standard, you know, meeting summarization agents or scheduling agents, things that are constantly doing some work in the background or respond to events and make you more productive or do things that you would want to do but don't have the time for.
And I think we're still very early when it comes to finding the various use cases for agents.
It's very, very early because a lot of people don't even know how to start building with agents.
And it's not as easy as it can be.
And we think that Render can make that easier over time.
Not just Render, I'm sure other companies will also work on this and are working on it.
But we're just at the very beginning of what I expect is going to be a very exponential, really rapid increase in agent development, not just in these tech forward startups, but also in larger companies as it becomes easier to do and as well-defined patterns emerge.
Because even the patterns for agents are changing every month.
What kind of harness?
Should it be a...
thick harness or a thin harness?
Should it be, where should you store state?
Should the harness be part of the sandbox or should it be outside the sandbox?
So all these questions are coming up every day.
And I don't think there is a given answer.
There's a unique answer to solving this problem universally.
I think different use cases will have different patterns.
And we're going to start to see those patterns emerge.
Yeah, I also think that like from my observations, the majority of companies are still busy with onboarding people to OOMs, partly convincing the devs.
I mean, I think that's mostly over since February or so.
And now, really figuring out how do software development life cycles change?
Yeah.
And I think, I don't know, what's your take on, I mean, this kind of a positive view that like, agents could be really like exponential at a certain point.
Do you think this will also change the trajectory on like the recent death of SaaS?
And yeah, let's say the seeming end of the indie hacker scene, like will this be as you can build an agent for everything?
your tax advisor might use agents, etc.
Do you think this will change?
I don't think so.
Because at the end of the day, you still need expertise to figure out if the agent's work is any good.
An agent is not going to become good by itself.
And someone needs to provide input.
I think supervised agents are the way to go for the foreseeable future.
At some point, I think we might make bigger advances, bigger leaps in AI, and suddenly you won't need to supervise agents as much.
But right now you have to.
I meant it also differently.
I'm absolutely on your end.
I think, yeah, you will need experts for that.
I'm more curious about the potential business trajectory or...
business chance behind that, right?
Is this potentially even the next SaaS that people sell agents?
Yeah, why not?
Exactly.
When you think about solo founders and what they can build, first of all, solo founders are able to build a lot more now.
I think that part is clear.
They're able to take many shots, many more shots on that.
We think, I think certainly that the nature of SaaS, of what kind of software people pay for, that is changing.
Just like people used to pay for B2B apps that were essentially a dashboard in front of a database because that was hard to build.
I think that dashboard thing is going to change, is changing, of course, because now everyone wants everything integrated with cloud or codex.
They want everything.
You want it to take actions, right?
You want it to make your day easier and to basically get the dullest stuff from your desk, right?
Yeah, and you want intelligence to be weaved into all the context that you have.
Because without that, it's just a role sitting in a database.
And we know that when you are able to combine LLMs with the context that your organization is producing through its users, through other means, that's really when you start seeing an increase in insights per day.
That's when you really start seeing true progress.
And so everything will be integrated with the chatbots that people already use.
And that's why we continue to see the rise of skills and MCPs.
Because if I'm already using ChatGPT, I don't really want to go into Render's dashboard to see what's going on with my app or to deploy my app.
I just want ChatGPT to do it for me.
And so that's going back to what I was saying.
We've really focused on making Render's CLI, Render's agent skills, Render's MCP server really friendly to agents.
And when you think about what people will pay for, I think people still will pay for maintenance and upgrades and specialization.
And yes, you can probably build some things that you pay for.
You can build on your own.
But think about the next time you want to add a feature to it.
Now you have to take yourself out of whatever it is that you were doing and now adding a feature to this thing.
And so I firmly believe that this whole thing about SaaS going away is overblown because people will continue to pay for software.
The nature of that software, of course, is changing and will change.
And I suspect that we'll have software.
become more infused with LLMs.
And you still will need expertise, business expertise.
You will still need product managers.
You'll still need engineers.
You'll still need specialization.
Specialization is the foundation of human civilization.
And so by saying that everyone will just build their own software, you're basically betting against all the ways in which humanity has flourished over the last thousands of years.
You know, we don't need every company to build a tax thing.
Have one company do it, do it really well.
Just like you don't need every company to build a platform to deploy applications.
Just let one company render, do it, do it really well.
And I think specialization will continue to exist as long as that exists.
people will sell software.
I on the other end think that engineers will become much more generalistic and everyone will become much more generalistic, but it's T-shaped, right?
Like you ultimately have your special features still, every engineer and your special signature, right?
Even though you overnight become journalists.
That's still what I believe.
So yes, I think it's a lot easier to understand fields of software engineering that you didn't before because LLMs are actually quite good at teaching you and answering your questions about why does something work that way.
And I'm talking about more specialization at the organizational, at the commerce sense, at the commerce level where exchange of value happens.
And especially when it comes to businesses or even consumers, right?
No consumer is going to build their own Instagram.
I mean, network effects are its own thing.
So I think businesses with network effects are probably safe.
But even for consumers to build their own iPhone apps, no one is going to sit down and do that.
Maybe if you're an engineer, you can do it.
And you might feel great about building one.
But most people never want to build.
any kind of software, that's not going to change.
You're right.
You're right.
I think Jason Fried recently wrote there, the people that actually like computers and the ones that don't, that this most likely is not going to change from his perspective.
And yeah, maybe like partly I agree.
I only think that, yeah, there's a category which still is...
I don't know, being born right now, which is the apps that people are building without knowing they are building, right?
And this is like a crazy chance also for companies like Google, right?
Or OpenAI.
I mean, there was this Super Bowl ad of Entropic against OpenAI and their ad thing, right?
Well, if you think about it twice, like if you have an LLM that kind of builds you some UI, which is kind of very well optimized because the same pattern that is being built there is repeating, right?
And there's like, there are like, obviously in this app, let's say you're traveling from A to B, you want to travel with your family and your two kids to France with an EV, right?
And you want to stop somewhere, make it family friendly, etc.
Like this will all drop out of Google.
I mean, it already does, right?
But it will potentially become a little app where you play around, etc.
And what at first sounded crazy, like, hey, Google is dropping their business model long term and clicks are going to disappear.
Now sounds like a super strong mode to me because you really, like if you have...
really like a strong UI that is custom tailored to the needs of the customer, then the likeliness of the customer to convert into whatever you offer him there on the trip to France, right, is increasing like crazy.
So I think this is a big chance that I think many people didn't yet.
really understand, right?
And why I'm super bullish on Google.
But that's just a little detour on that word, right?
No, I agree.
I think this is a really good point where the right solution to someone's query is not a wall of text, but an interface or a web app.
And there are lots of queries like that.
And you can imagine that Google gets really good at building out travel itineraries that are entirely interactive and that give you multiple options and you can change things.
And so this is a very customized to you thing.
But stuff like that wasn't possible even six months ago.
And even now you'll have to, you know.
It's not something that exists today.
I think software coding agents have to advance a little bit further to get there, and I think they will.
But that is probably the world we're going towards where companies will construct applications on the fly, or agents will, and then they will deploy these applications on the fly.
And that's also something that Render is preparing for, where I think that the vast majority of compute running in the cloud in maybe two years is going to be compute generated on the fly by agents.
And as opposed to any human ever having gone through the software development lifecycle to get that software in the cloud.
Yeah, I agree.
Slightly touching distribution and how distribution will change.
Like, what's your take on that?
I mean, you build a tool for developers, let's say by developers for developers, which is a special mode.
And I would say now really a very good one, right?
As I guess your growth trajectory is quite nice.
But what happens to the others?
Like, how do you see this?
Like, also maybe from patterns you observe on your platform.
How do you see growth and shipping software really changing?
And how does marketing work in that world?
Like, whenever someone throws over some software on my desk, I start being afraid because there's so much software popping up everywhere.
Like, what do you think will be a strategy, a go-to-market strategy for the future?
I don't know about the far future, but in the short term, over the next year, two years, the best thing anyone can do is to figure out how to get ChatGPT and Cloud to recommend their products for the relevant queries.
Because increasingly, and Gemini.
Because increasingly, that is how this is happening.
SEO itself.
I mean, there are some things that you do for SEO that are also good for GEO or Generative Engine Optimization.
And Google released something around this a week or two ago.
But fundamentally, people are going to stop asking, even asking their friends.
They're actually just going to ask chatbots about what to do, which product to use, which vendors.
And the good thing is that the answers here are actually typically more customized to you than a series of blue links on a page, right?
And you can go back and forth and customize them, personalize these things even further and ask it for more recommendations of a certain type or ask it to change direction.
So product discovery is much...
much, much better as an experience with chatbots than it was with Google.
And it's actually better than asking your friends also or asking Twitter.
So really distribution is going to, all the investment in distribution is going to go into how do you get chatbots to surface you in the right answers.
And if you're not working on that right now, then You should start.
And long term?
I think long term, it's going to likely get polluted by ads.
And so we'll go back down to who has more money to spend on ads than surfacing yourself.
The other piece that I do think people should think about is chatbots are the answers they give you.
They're a combination of the signals that are already present in the web, right?
And so you have to think about what people are saying about you online.
It's not just chatbots.
You have to think about what people are saying about you online.
You have to think more about your reviews on a review forum.
You have to think about influencer marketing.
You have to think about presence on Substacks and Wikipedia.
Reddit, absolutely.
So all of those things, human signals on the web is how chatbots decide a lot of this today.
The problem is that a lot of those signals are and can be gamed, are being gamed through AI.
People are generating this data through AI.
And so I think we're in for a bit of a war between these chatbots and everyone trying to gain the chatbots.
Just like Google fought SEO spam, especially in the early 2000s.
I think SEO spam was a major, major problem for Google.
They eventually figured it out.
I think all the chatbots will need to figure that out over the next like five years.
Yeah, right.
They're not necessarily links anymore, right?
And that makes it way harder than it was before.
It makes it way harder because you don't actually...
This is why it's so important to understand why something is being recommended.
And I mean, even, you know, trans-GPT researchers aren't sure why something, why the answer is what it is.
It's a probabilistic machine.
So the answer is different every time too.
So, you know, it's going to be very interesting to see what happens here.
Yeah, that's funny that still the majority of LLMs uses Google for grounding, right?
Like uses search for grounding or Google or Brave or whoever's out there, right?
And fires queries to ground the probabilistic answer with deterministic facts, which is in a way strange and really speaks for Google's power, right?
In this time.
I think Google is being underestimated still.
And over the long term, it's going to be very hard to, unless they screw things up in some major way, it's going to be very hard to outcompete Google, given the end-to-end stack ownership that they've built.
Yeah.
I'm with you.
Like, even though there was this initial Google is done, right?
When ChatGPT was launched, that narrative really changed.
And also if you look at the public markets, that really didn't age well.
So we slowly have to come to the end.
And it's a great discussion.
I have many more questions on my list, which didn't make it and so much more to discuss.
Maybe if we can be more concrete for the CTOs out there, whose team is going all in on agents this year, like independent of which cloud they pick, let's say.
I mean, obviously, like everyone will go into render now.
What do they get right?
And what do they stop wasting time on or should they?
Yeah, I think the biggest problem that we see with people building agents is actually observability.
How do I know that my agent is doing the right thing?
How do I know that the answer it came to?
How do I know the steps involved in that answer?
And when something goes wrong, how do I fix it?
There's a lot of work that needs to go into tracing the actions of an agent so you can fully build reliable agents.
There's a lot of work that goes into evals, of course, and building the right evaluations.
And it's very easy to spin up a demo for an agent, but it's...
incredibly hard to do a great job in production where there are a lot of edge cases and the context can be quite different.
And so I would be very careful about believing demos and I would think hard about the end-to-end architecture before going all in because it is going to be a significant investment no matter what.
And you need to think hard about the tools that you'll need and the architectures and how you're going to justify ROI because we're also now entering the world of companies saying, oh, we spent all this money on tokens, but we didn't really see any improvements.
I don't know, I think, was it Amazon that canceled a bunch of cloud code subscriptions and Uber CEO saying all the spending on tokens isn't really leading to usage.
So I don't think that should stop anyone from experimenting.
And I also think that the tools to build agents, just like Render's doing.
other companies too, will make it easier to build agents.
And so the tools to build them will improve.
And that means more people will be able to experiment more with agents and will not have to do all the undifferentiated heavy lifting, as we call it, for what it means to build an agent.
Thank you.
I still have a little surprise for you.
So someone from your team, like I got in touch with earlier, told me you left a little, you yourself left a little hidden Easter egg in the render dashboard.
If you try to deploy a service to a region that doesn't exist and hit deploy three times, the build log starts scrolling backwards and drops you into a past year.
Now imagine we now, like, hit deploy three times.
and watch the log start rolling backwards.
And we land in the year 2011 in August, when you first started at Stripe.
And we now watch yourself for a little while, like you are like holding a lot, like getting started with risk management a little bit already.
And you now have the chance to whisper something into your young self's ears.
What would you tell yourself?
I would certainly tell myself to be more thoughtful when it comes to how different components in a business interact.
When you're not the founder, you don't really think hard about that.
someone who works at a company, if you understand how the different components work and how all of that works to achieve the final output, it makes you better at your job.
And then obviously in my case, I ended up starting a company.
It would have made me a better founder from the get go.
So yeah, just be more curious about other parts of the company and try to learn as much as you can about other functions.
You also just get to know people who could become your coworkers later.
Yeah.
So the bootstrapping phase was a bit harder, I guess, then initially or?
Yeah, I think it's not just the bootstrapping phase.
Different functions are useful at different parts, different.
stages of the company.
But as an engineer, you need to learn a lot more about company building than you do when it comes to just building products.
And the more you can, at least for me, that's what I would tell myself because I ended up starting a company, is to get more into the language of the business, get more into the finances, learn more about the revenue and the implications and growth strategies and so on.
And at least Stripe was always a place where if you had questions about something, people were willing to give you answers.
Like it wasn't, you know, it wasn't Apple where everything would just be secret.
And so I would say the same thing to people at Render now.
We are very transparent internally.
Everyone knows what's going on with the company financially day to day.
And you can ask anyone.
You can DM me if you're at Render.
You can DM me at any point and ask me a question and I will answer.
So use that.
use your ability to learn more about business if you one day want to start a company.
Thank you, Anrak.
Quite a nice discussion.
Wish you all the best for Render.
Thank you.
Folks listening, check out his service.
I mean, most of you know Render already.
Maybe like a little starting point for building agents on Render.
Is there something you can recommend or is it just like going to the homepage and...
Just go to the homepage.
Yeah.
And we have a bunch of templates for agents that we're going to publish soon and they'll be on the homepage.
Okay, cool.
Thanks a lot, Anerat.
Hope to see you soon.
Thank you, Toby.
Thank you very much.
Bye.
Thank you for listening to the Arthelist podcast.
If you liked this episode, share it with friends.
I'm sure they love it too.
Make sure to subscribe so you can hear deep insights into technical leadership and technology trends as they become available.
Also, please tell us if there is a topic you would like to hear more about or a technical leader whose brain you would like us to pick.
Alphalist is all about helping CTOs getting access to the insights they need to make the best decisions for their company.
Please send us suggestions to cto at alphalist.com.
Send me a message on LinkedIn or Twitter.
After all, the more knowledge we bring to CTOs, the more growth we see in tech.
Or as we say on Alphalist, accumulated knowledge to accelerate growth.
See you in the next episode.