Founder Interviews: Anurag Goel of Render
After leaving his position as Head of Risk at Stripe, Anurag Goel started Render, a cloud platform where developers and startups can host any application or website quickly and easily. Render now serves more than 80 million requests every week.
What’s your background, and what are you working on?
I am the founder of Render, a cloud platform where developers and startups can host any application or website quickly and easily. I was previously the Head of Risk at Stripe where I helped the company launch in 2011 and grow to $5B in valuation by the time I left in 2016. I also created Crestle, an AI infrastructure company which was acquired by doc.ai in 2018.
At Render we’re making it effortless to host applications in the cloud. Traditionally, developers have had to pick between large cloud providers like AWS which are complex and difficult to use, or Platform-as-a-Service solutions like Heroku which are prohibitively expensive especially as your app scales.
Render gives you the best of both worlds: instant setup and ease of use as well as the power and flexibility previously only available on large clouds. From simple React sites and Rails apps to complex applications like Elasticsearch and Kafka, Render is an easy and cost-effective platform to host everything from a weekend project with a single static page to a rapidly scaling startup with tens of containerized microservices.
Thousands of developers and startups have joined Render since we launched in April 2019, and we’re now serving more than 80 million requests every week.
What motivated you to get started with your company?
I was solving my own problem. After I left Stripe, I had time to figure out what I wanted to do next, and I dabbled in a few different domains like healthcare, real-time infrastructure and natural language processing. I created simple apps in each of these domains to better understand problems I’d be excited about, but hosting these apps on existing cloud platforms was always painful. I was forced to go through the same steps over and over again, and each step involved complex configuration in addition to tedious post-launch maintenance. I wasn’t alone in this either; my friends were going through similar issues with apps of their own and we were all complaining to each other about how running an app in production was still a miserable experience.
This was when I first considered building Render, but decided not to because the problem seemed too big to tackle and I figured ‘someone else would fix it’. Instead, I dug deeper into AI, and as I was taking an online deep learning course offered by fast.ai, I noticed how everyone was struggling with running Jupyter on AWS. I was still looking for problems to solve, so I decided to build Crestle, which lets anyone spin up a GPU-backed Jupyter notebook in the cloud with a single click. It was really well received, and for a while I considered building Crestle into a larger company. However, I soon realized that I wasn’t excited enough about the problem to work on it for the next ten years, which is how long it takes to build something truly useful and enduring.
But building Crestle gave me a lot of insight into Kubernetes and Docker (which are both spectacular advancements in application packaging and deployment), and it helped me connect the dots and finally conceptualize a cloud platform that would be both incredibly easy to use and extremely flexible and powerful. In the end, I think I just got tired of waiting for large cloud providers to get better at user experience, and decided to build the cloud I’d always wanted for my own apps.
What went into building the initial product?
I first started working on Render in July 2017, and the initial version was a serverless Python coding environment in the browser that interacted with an API backed by Kubernetes and Docker. It was great for building quick HTTP endpoints and getting instant feedback on your code, but after a few months it was clear that most apps wouldn’t be able to run on it without creating strong vendor lock-in (like with AWS Lambda). I realized that for Render to run most real-world applications I had to build out a more generic platform; so I switched tracks and built out the second iteration of Render in late 2017/early 2018. This prototype was built to host regular Python, Node, and Ruby web apps with instant, continuous deploys from GitHub. I shared it with my friends who were excited about it, and when they started using it for their own projects it was clear that Render was useful enough to poke at further.
This is when I decided to raise a seed round so I could build out a team and expand beyond the prototype. Steve Herrod from General Catalyst (also early investors in Stripe) led the round, and Ruchi Sanghvi at the South Park Commons Fund helped me kickstart the fundraising process and also served as a sounding board throughout. They’ve both continued to be very helpful.
But funding is only part of the equation; not long after I finished raising, Adrian Duong and I met through a mutual friend and I convinced him to join me on our ambitious journey. Ralph Landon and Maša Mlakar joined later in 2018, and together we built out the initial platform that launched earlier this year. We’re continuing to build our engineering and design teams in SF, and I feel very thankful for the amazing group of people I get to work with every day.
Render’s tech stack hasn’t changed significantly since early 2018. We picked Go for the backend because we interact closely with Kubernetes and Docker (which are both written in Go), and because it had a lot of momentum and prior art as an infrastructure language. It also helped that it was blazing fast and great for concurrent programming which we ended up doing a lot of even early on. Our frontend is a React dashboard which interacts with our Go API through GraphQL (using Apollo Client). We started out with a monolith and have since broken it up into a few different services to increase fault-tolerance and allow for independent scaling.
We’ve found our current stack to be reasonably productive, but Go can sometimes be more verbose that I’d like (insert obligatory rant about lack of generics). If I were building a webapp that didn’t involve building infrastructure, I’d probably pick Python or Elixir because it’s easier to be more productive with them. However, Go still remains the best option for building fast, scalable and reliable infrastructure, which is of course our bread and butter at Render.
How have you attracted users and grown your company?
We launched Render in invite-only access in the summer of 2018. Most early users were developers in our personal networks, but soon we started seeing users we didn’t know personally. This happened entirely through word of mouth, and also because Render ended up being the easiest option for fast.ai model deployment, which meant that most students taking the course used Render by default.
After a few months it was clear we were ready to launch formally, so we opened signups at the end of April this year. This was a major turning point; it got us a lot of attention from multiple outlets, which snowballed into thousands of new users many of whom became extremely vocal Render supporters. If you search for @getRender or render.com on Twitter you’ll see our users spontaneously telling their followers about us because they love the product, and word-of-mouth continues to be our primary growth channel.
We’ve also created guides to deploy a lot of different frameworks and applications on Render (available at https://render.com/docs) and they’re very helpful for our users, and are also becoming a material growth channel through Google searches for ‘how to deploy X’. Another avenue that’s worked well is links to Render in documentation for popular open source projects. Render is now an official deployment option for Gatsby, Create React App, Hugo, Vue and many other widely used open source frameworks, and we’re seeing an increasing number of users discovering us through these channels.
There’s much more we can and need to do for growth, but the best kind of growth has always come from improving our product in ways that expand its reach. Adding support for GitLab and enabling block storage for Render apps are two examples where we significantly expanded the potential use cases Render enables. We believe sustainable, cost-effective growth can only happen through word-of-mouth, which means really sweating the details and building something users love so much they want to share it with everyone they know.
What’s your business model, and how have you grown your revenue?
Our business model is quite simple: we charge for hosting. We have a free plan for static sites, but everything else is a paid service. When we launched Render’s private beta in early 2018 we spent a lot of time on pricing and also involved early users in these discussions, and we’ve continued to refine it since then. Shortly after we launched, we introduced new paid products and pricing plans which are all available at https://render.com/pricing. There are a couple of lessons I’ve learned about pricing: you have to experiment, and as a startup you have to fight the urge to underprice. Render is not the least expensive option to host an app, but it is the easiest and most cost-effective. We save our users a lot of time which translates to real money, especially if you don’t have to hire devops engineers who’re quite hard to find and recruit.
Somewhat unexpectedly, our revenue growth has far outpaced user growth, which seems to be a good sign. We think it’s because once our users discover how easy it is to spin up a service on Render, they end up transferring all their services over to us. We’ve seen this happen repeatedly for users previously on Heroku and AWS. Also, when you make something extremely easy to do, people will naturally do more of it, so we’re seeing users deploy apps they wouldn’t have put in production otherwise; this is quite gratifying because we’re empowering more people to share their creations with the world.
What are your goals for the future?
Our overarching goal is to continue to simplify deployment and hosting for all kinds of apps, to the point where Render is the default choice for anything you’d want to run online. We’re building Render for the very long term, and in the best case it’s a multi-decade endeavor so our goals are commensurately ambitious. We’re working to achieve them one day at a time by listening to our users and building Render with a relentless focus on user experience. There is a lot of work ahead of us, but the feedback we’ve gotten so far is very encouraging so we’ll continue to do our best for our users.
In the short term, we’re focused on enabling more use cases and applications on Render. We recently launched the ability to create and mount disks for any Render app, and this lets you run complex stateful applications like Elasticsearch, Kafka, and MongoDB. We’re also working on integrating best-in-class logging and monitoring services so our users can get better visibility into their workloads. Finally, a lot of developers are waiting for Render to offer hosting regions in Europe and Asia, so we’re working on making that happen.
What are the biggest challenges you’ve faced and obstacles you’ve overcome? If you had to start over, what would you do differently?
As I mentioned earlier, the first time I thought about building Render it felt too big to take on and I kept the idea on the back burner for almost a year. That was clearly a mistake. Ideas that seem too broad or ambitious can sometimes be the best ones because very few people are working on them, and even though they seem intractable at first, there’s often a different way of looking at the problem that helps you get started and make headway. Once we started building Render, it became obvious that we could make it much more usable than all the existing options, and that developers cared enough about UX to willingly migrate their apps from established providers like AWS and Heroku to a new startup like ours.
Have you found anything particularly helpful or advantageous?
It was helpful to see Stripe grow from a handful of people to a few hundred, because I saw firsthand what worked (and what didn’t) as the company scaled. It was also helpful to join the company pre-launch and to know that it was in private beta for nearly two years; in a world where startups are built and launched over a weekend, sometimes it does make sense to think long and hard about the product you want to build and take the time to get it right.
It was also very useful to be part of a technical community like the South Park Commons as I was building the first version of Render. Even though the product was invite-only, I invited (read coerced) everyone around me to use it and received invaluable feedback that continues to inform our product decisions today.
What’s your advice for entrepreneurs who are just starting out?
I’ve found intellectual rigor and discipline to be both invaluable and underrated: these are two of a very small number of things that are entirely under your control as a startup, and I wish more companies practiced them diligently. Thinking hard isn’t always fun (as humans we’re unfortunately hardwired for intellectual laziness), but it does lead to products that stand out and solutions that have been overlooked. Similarly, the discipline to focus only on things that need to be done (as opposed to things that seem vaguely useful but more fun) is crucial. There are always an infinite number of things to work on at a startup, but time is the most precious resource you’ll ever have, and ruthless prioritization is essential.
I’d also recommend taking to the time to find an idea or space you care deeply about before starting your company; founder-idea fit is at least as important as how big your market is or who you end up working with. In the best case, you’ll be working on your company for a decade, so you have to be truly excited about the space or risk burning out fairly quickly.
Finally, I’d question all entrepreneurial advice (including the above) because everyone’s talents, skills and circumstances are unique; this makes it very hard to give generic advice that’s truly useful, but very easy to ascribe successful outcomes to specific actions and to ignore the role luck plays in any startup’s evolution.
Where can we go to learn more?
You can learn more about Render at https://render.com and follow us on Twitter at @getRender. You can also ask me anything and I’d be happy to help if I can. I’m available in Render’s community chat at https://render.com/chat and on Twitter at @anuraggoel.