Anurag Goel grew up in New Delhi, but moved to Boston after college for his first job. He worked at Stripe, as the 8th employee, before eventually moving on and launching his current venture. Outside of tech, he is married, living in San Francisco. He likes to read science fiction, especially prior to bedtime. He also enjoys eating Thai food on the regular, though he mentioned he could eat pizza every day.Post leaving Stripe, Anurag decided to work on an ambitious problem, and he started doing this by building a bunch of stuff in many different domains. After noticing a common problem in building out Kubernetes, he decided to start a new business to abstract these problems, and allow builders to focus on the differentiating factors to their solutions.This is the creation story of Render.SponsorsSpeakeasyLinkshttps://render.com/https://www.linkedin.com/in/anuragoel/Our Sponsors:* Check out Vanta and use my code CODESTORY for a great deal: https://www.vanta.comSupport this podcast at — https://redcircle.com/code-story/donationsAdvertising Inquiries: https://redcircle.com/brandsPrivacy & Opt-Out: https://redcircle.com/privacy
As soon as I got our first users onto the platform, I have always relied on their input and feedback. And obviously users have a specific, everyone on Render has a specific problem they're trying to solve. And sometimes they might come up with the solution itself, but it's our job to truly pull out the problem that they're trying to solve so we can solve it in the way that makes the most sense.
We have been obsessed about getting customer feedback every day. That has been, I think, the most influential piece on our roadmap. My name is Anurag Goyal, and I'm the founder and CEO at Render.
This is CodeStory. A podcast bringing you interviews with tech visionaries. Who share what it takes to change an industry. Who built the teams that have their back. Keeping scalability top of mind. All that infrastructure was a pain. Yes, we've been fighting it as we grow. Total waste of time. The stories you don't read in the headlines. It's not an easy thing to achieve.
Took off the shelf and dusted it off and tried to begin. To ride the ups and downs of the startup life. You need to really want it. It's not just about technology. All this and more on CodeStory. I'm your host, Noah Labhart. And today, Anirag Gold has built you the fastest path to production, from your first user to your billions. This episode is sponsored by Speakeasy.
Grow your API user adoption and improve engineering velocity with friction-free integration experiences. With Speakeasy's platform, you can now automatically generate SDKs in 10 languages and Terraform providers in minutes. Visit speakeasy.com slash codestory and generate your first SDK for free. This message is sponsored by QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Grotta, and Autotrader, you're in good hands. Join the Wolfpack at QAwolf.com.
Anurag Goyal grew up in New Delhi, but moved to Boston after college for his first job. He worked at Stripe as the eighth employee before eventually moving on and launching his current venture. Outside of tech, he's married, living in San Francisco. He likes to read science fiction, especially prior to bedtime.
He also enjoys eating Thai food on the regular, though he mentioned he could eat pizza every day. Post leaving Stripe, Anurag decided to work on an ambitious problem. And he started doing this by building a bunch of stuff in many different domains.
After noticing a common problem in building out Kubernetes, he decided to start a new business to abstract these problems and allow builders to focus on the differentiating factors of their solutions. This is the creation story of Render.
So after I left Stripe, I was in this position where I could do anything or nothing. And I chose to work on a really ambitious problem for the rest of my career. In order to find that right problem, I had to go build, or my strategy at least was to go build stuff in a lot of different domains. I'm a builder at heart.
And as I was putting a lot of these things into production, as I was using some of the tools that we all use, Kubernetes, AWS, I realized that every Kubernetes setup I had looked pretty much the same. And then I realized that most companies really end up doing the same kind of work on top of AWS and Kubernetes and then using other managed services.
It's just not differentiated enough, and it's also too complex for what it gives you. And I think companies want the benefit, and I wanted the benefit of autoscaling, of private networking. I wanted to have persistent storage, but I really didn't want to mess around with everything that you have to mess around with. In some cases, hundreds of thousands of lines of Terraform or YAML.
I decided that this was a big enough problem and an ambitious enough problem that I personally was really excited about. That's because it combines my passion for developer experience and developer productivity. I had done all this infrastructure work over the course of the last 15 years of my career, and it made sense for me to combine the two and start Render as a result.
So Render is attempting and is successful to a large extent. to remove all the undifferentiated complexity and the cost of building out your own Kubernetes-based infrastructure on top of one of the large public clouds. But it gives you the same functionality, so there's no compromise on things like autoscaling and the stuff that I mentioned earlier.
There is no compromise on those fundamental things that people want out of Kubernetes, which is why they use Kubernetes. As a Render customer, all you do is interact with Render's interfaces and you never have to think about writing a single line of YAML or even opening an AWS account. And it's an all-in-one solution.
Tell me about the MVP. So that first version of the product you built, how long did it take to build and what sort of tools were you using to bring it to life?
I first built the prototype during the winter break 2017, early 2018. It took me about, I think, a couple of weeks. I built it in Python because that was my preferred language of choice. And I built everything on top of Kubernetes, like I said, and AWS, actually at the time GCP.
the intent of the prototype or really the MVP, because it was more than a prototype, it was serving production apps even then, was to get people to just try the thing out. What it could do at the time was mostly just host a Python backend. And it made a lot of sense to me to start there.
But also as soon as I shared it within my friends and the community that I was part of, everyone's instant reaction was, yes, I want this. And whether it was the interface or lack of complexity, everyone got really excited about it. Not all of these people were my friends. I knew them, but not all of them were friends.
So it wasn't like, oh, we like you, therefore we're going to tell you good things about your product. And at that point, I truly realized that there is something here based on my own experience and I already know how to build it. And now I had to go start a company to make sure that we can build it fast, we can build it scalably, and that we're actually building a business.
Tell me about that process you went through in building that. You still got to make certain decisions and trade-offs and deciding on what you choose. So I heard you choosing Python because that was your language of choice. Tell me a little bit more about some of the decisions and trade-offs you had to make in that early version and how you cope the decisions.
was clear to me that I am compromising on resource use and efficiency with an interpreted language like Python. And then I just rebuilt everything in Go. And then I benchmarked requests against Python and my Python and Go implementations. And Go was just way better in terms of resource utilization, in terms of just speed, latency.
I just, I had to rewrite everything in Go and that happened over January and Render has been a Go shop ever since.
This message is sponsored by SnapTrade. Link in-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This episode is sponsored by Speakeasy.
Whether you're growing the user adoption of your public API or streamlining internal development, SDKs can turn the chore of API integration into effortless implementation. Unburden your API users from guessing their way around your API while keeping your team focused on your product. Shorten the time to live integration and provide a delightful experience for your customers.
With Speakeasy's platform, you can now automatically generate up-to-date, robust, idiomatic SDKs in 10 languages and Terraform providers in just a matter of minutes. SDKs are feature-rich with type safety, auto-retries, and pagination. Everything you need to give your API the developer experience it deserves. Deliver a premium API experience without the premium price tag.
Visit speakeasy.com slash codestory to get started and generate your first SDK for free. You've you've written the prototype. You're getting the good feedback. You're ready to move forward and build the company. Tell me about how you progressed the product from there and matured it.
And I think to wrap in a box a little bit, what I'm looking for is how did you go about building your roadmap and then and now? And what criteria are you using to decide, OK, this is the next most important thing to build or to address with Renderer?
As soon as I got our first users onto the platform, I have always relied on their input and feedback. And obviously, everyone on Render has a specific problem they're trying to solve. And sometimes they might come up with the solution itself. But it's our job to truly pull out the problem that they're trying to solve so we can solve it in the way that makes the most sense.
We have been obsessed about getting customer feedback every day. That has been, I think, the most influential piece on our roadmap. We are nothing, the business is nothing without the customers who trust us with their production workloads. And our goal is to continue to listen to them and build what they want.
I hear you saying we. Tell me about how you built your team. And what do you look for in those people to indicate they're the winning horses to join you?
So our team was fairly small for a long time. Our first engineer, Adrian, he joined me in April of 2018. And then the team was mostly four people until we launched on TechCrunch Disrupt battlefield stage in October 2019. And then we ended up winning that competition. If you've seen Silicon Valley HBO, the HBO show, you probably know what I'm talking about.
So that was a pretty interesting moment for us where a lot of people heard about us for the very first time. And we started seeing more momentum and it allowed us to invest in growing out the team further by going the venture capital route and making sure that we had enough of a runway to continue to build the things that we just knew we needed to build to make this a complete platform.
And the things that we look for, that we've always looked for, are actually on our website under our careers page. And I would love for people to go to vendor.com slash careers, where you can see the high level values of ownership, of optimism and ambition, of focus on quality, and then a focus on being really thoughtful about
a given problem and reasoning very clearly about it instead of just rushing to implement it. Once we reason clearly about something, then we actually move fast, we execute fast to implement it. Render is a very long-term project and company. I want to work on this, ideally, for the rest of my career. There is enough scope here, so we have to take the long view.
We really have to focus on long-term employee happiness, making sure that people are here for the long term, they value being here for the long term, and that they know that this is not going to be a four or five or even a 10-year project. journey that they are part of. And then that's it. The company either sells or it goes public and then everything slows down.
And so Render, again, everyone at the company knows that this is a multi-decade endeavor. Regardless of how long they stay at Render, that's how we approach what we build every day.
This message is sponsored by SnapTrade. Link end-user brokerage accounts and build world-class investing experiences with SnapTrade's unified brokerage API. With over $12 billion in connected assets and over 300,000 connected accounts, SnapTrade's API quality and developer experience are second to none. SnapTrade is SOC 2 certified and uses industry-leading security practices.
Developers can use the company's official client SDKs to build investing experiences in minutes without the limitations of traditional aggregators. Get started for free today by visiting snaptrade.com slash codestory. This message is sponsored by QA Wolf. If slow QA processes bottleneck your software engineering team and you're releasing slower because of it, you need a solution. You need QA Wolf.
QA Wolf gets engineering teams to 80% automated end-to-end test coverage and helps them ship five times faster by reducing QA cycles from hours to minutes. With over 100 five-star reviews on G2 and customer testimonials from SalesLoft, Drada, Autotrader, and many more, you're in good hands. Ready to ship faster with fewer bugs?
Join the Wolfpack at QAwolf.com to see if they can help you squash the QA bottleneck. My next question will be super interesting. Given what you've built, was this built with scale in mind from the very beginning? Obviously it was, but have there been any interesting areas where you've had to fight it as you've grown?
Oh, yeah. So the 20 is a 2018 Pete Buttigieg presidential primary campaign. They decided to host the campaign on render. And we learned pretty quickly that there were these bottlenecks in the system. every time he delivered his closing statement on stage. So we're all there monitoring everything, making sure that we continue to remove these scaling bottlenecks.
Even back then, I'm talking about 2018. And now our system serves over 50 billion requests every month. And we are signing up a very large number of developers every month who end up creating millions of applications and have created many millions of applications on Render over time.
And a lot of those applications have then gone on to expand themselves to hundreds of thousands, sometimes millions of users, which means that our platform has continued to scale with them. That was one of my biggest needs coming out of what I wanted out of Render. And that's because it's still hard, but it's relatively easy to build something that just helps you get started quickly.
It's much, much harder to build something that scales with you over the very long term, where you don't have to then say, okay, we've reached the limits of this platform, and now we need to hire a bunch of developer operations people and platform engineers. And now we need to go build all of this ourselves on AWS and use Kubernetes or what have you. And that has never been an option for Render.
So what that means is we continue to execute on improving our platform, not just in scalability, but also in capabilities that allow people to grow with us and not have to worry about moving on.
So as you step out on the balcony and you look across all that you've built to render, what are you most proud of? There's obviously lots to be proud of there, but tell me what comes to mind for you.
I think I'm most proud of the feedback the love that the developer community has had for Render and the fact that it continues to grow. I never wanted to build a product that was just for five companies with very large deal sizes. What Render is doing is relevant for every developer on the planet.
And to see our growth and the love that we see on Twitter, on Product Hunt, on Hacker News, that's all. That's the thing that I think continues to refuel me and our team. And I'm really proud of that.
Okay, let's flip the script a little bit. Tell me about a mistake you made and how you and your team responded to it. And I know there's scalability issues and things like that we already talked about, but less about growing pains and more about a mistake.
Render has grown to where it is without any real marketing lift. And the only thing we do for marketing is our free tier, if you can call it that. I wish that I had built out a mature marketing team sooner. Regardless, I think our product has helped us win We've more than doubled our revenue over the last year, and it continues to grow entirely on the basis of organic growth.
And while that's great, it means that we're also leaving a lot of money on the table. And I would like us to grow faster so we can go hire more great people. That is where I think I should have focused more sooner.
This is your lifelong problem you want to work on, or you want to work on this problem for the rest of your life. What does the future look like for the product and for your team?
The future looks like everyone is running not just their production workloads or their staging workloads, but also their development process and their whole pipeline on render. And we're helping them move fast every step of the way from the first line you write to when you scale your product.
allow it to serve millions and millions of people and what render does today is certainly a big part of that but we want to make sure that given our unique position in the developer workflow which is really we present people's work to the world we also and given our unique position because of
Our end-to-end platform, which has your web service, your static site, your API, your database, your cache. We can do a lot more to improve the process of going from coding to production. And then obviously as the platform, I think we have many more capabilities that allow increasingly large companies to migrate to us.
This is just a short term, but ultimately, I think the goal for Render is to significantly accelerate software innovation and speed of iteration combined with the reliability and stability of our platform and just the features that you want.
so that you can truly focus, especially as a very large company, as an enterprise, you can still truly focus on building your business and your products and not on the undifferentiated work, that tax that you have to pay today. And I think we're still stuck in many ways. In 2005, when AWS came to the scene and introduced a slightly different or somewhat different abstraction to the cloud
You know, a lot of people laughed at them back then. Oh, this is never going to scale. This is for toy companies. And we are here in 2024. And I think the future is going to be guided by history repeating itself, where Render leads the way in bringing a new abstraction level for the cloud that does so much more than what is possible today.
Let's switch to you, Anurag. So tell me who influences the way that you work. Tell me about a person or many persons or something that influences the way you work on a day-to-day basis.
Two major influences for me. One, just learning from others who have gone before me through reading books, blog posts, to trying to talk to them and getting advice and learning to not make the mistakes that they made and trying to figure out how Render can move faster as a result. And the second major influence is, of course, the people at Render.
And I learned something new about building a growing organization every day by just working with our team and being really close to everyone at Render. I interview every candidate we're close to making an offer to today. And I don't intend to stop until, really until I decide that I just can't do it anymore, right?
especially as you build a company and a culture, which is very unique to how you started. There are a lot of learnings to be had by just doing and making sure that we're constantly reflecting on how things are going, where the gaps are, but also how as CEO, my job has changed significantly and it changes every six to nine months. And that's only because of the organization and what it needs.
And so that is a huge influence on how I think. Last question, Anurag.
So you're getting on a plane and you're sitting next to a young entrepreneur who's built the next big thing. They're jazzed about it. They can't wait to show it off to the world and can't wait to show it off to you right there on the plane. What advice do you give that person having gone down this road a bit?
The advice I give young founders especially, but really any founder, first and foremost, you should be incredibly excited about the product you're building. That can come from domain expertise. It can come from personal experience. It can come from just learning more about your customers.
But if there isn't enough of a founder market fit, then you're not going to succeed or at least not going to succeed to the level you would want to as a founder. And a lot of people can build companies and spaces that they're not excited about.
But the eventual outcomes for those companies, in my experience, has always been less than what they could have achieved if the founder or the founders were much more excited about the domain and could truly bring what they've learned to the problem in a way that solves it in a new way. And startups are a slog either way.
So why not work on something that you think you can truly bring uniquely to the world? And in the best case, you're going to be working on it, like I said, for the rest of your career. And you need to find something that you really love.
I think that's fantastic advice. So, Hanirat, thank you for being on the show today. Thank you for telling the creation story of Render. Thank you.
Thank you for having me. I enjoyed this a lot.
And this concludes another chapter of Code Story. Code Story is hosted and produced by Noah Laphart. Be sure to subscribe on Apple Podcasts, Spotify, or the podcasting app of your choice. And when you get a chance, leave us a review. Both things help us out tremendously. And thanks again for listening.