All episodes

Anurag Goel - founder of Render

Render founder Anurag Goel explains how to combine AWS-scale capability with an approachable developer experience: obsess over customer goals, reveal complexity only when it becomes useful, and treat support as part of the product.

Jack Bridger
Episode 10140:33

Anurag Goel founded Render after joining Stripe as its eighth employee and seeing how much engineering effort even a fast-growing technical company spent managing cloud infrastructure.

We talk about founder-market fit, progressive disclosure, helping a customer grow from a tiny bill to millions in annual spend, the product value of support and error messages, and the Stripe lessons Anurag carried into Render.

The Q&A below is experimental — extracted from the episode transcript with AI. If you spot a mistake, let us know at jack@scalingdevtools.com.

Why did you decide to build Render?

At Stripe, one of the first four engineers managed AWS and that infrastructure share stayed meaningful as the company grew. After leaving, I tested possible founder ideas by building applications and repeatedly encountered the same broken deployment experience: simple platforms lacked capability, while AWS required low-level expertise. Render began as a way to offer cloud power without a large DevOps organization.

What changed after Render’s public launch?

Four of us launched a limited product at TechCrunch Disrupt in 2019 and won the Battlefield competition, which put Render on the map. The years after were about turning that starting point into a capable, performant platform able to automate the work a complex application would otherwise require on AWS.

Why hasn’t cloud infrastructure become easier at the same rate as application development?

AWS changed the economics of owning servers but continued building for systems specialists. Most developers do not want to become low-level cloud engineers, yet their applications still grow in traffic and architectural complexity. The missing layer is an experience that keeps that power while changing who can operate it.

How can the same platform serve a $30 customer and a million-dollar customer?

Stay focused on the customer's goal rather than forcing a prescribed architecture. Give teams the levers they need as they grow, keep an ongoing conversation and try to remain several steps ahead. Features built for customers scaling on Render also become the capabilities that persuade already-large enterprises to move workloads from Kubernetes and public clouds.

What is progressive disclosure of complexity?

Do not place hundreds of services and decisions in front of a new user. Keep the dashboard appropriate for the common path, then expose private networking or other advanced needs when the relevant customer reaches them. The deeper capability can live in an API or Terraform provider instead of making the first-run interface harder for everyone.

What does “talk to customers” mean in practice?

It begins with empathy and repeated questions about what somebody is actually trying to achieve. Do not automatically bend their need toward the feature you already have, or implement their proposed solution without finding the underlying job. Founder-market fit helps: I am a developer, enjoy these conversations and hire technical people who understand the experience personally.

Why should customer support be treated as product work?

As the community grows, users increasingly help one another, but Render still watches public conversations and responds. Each question can improve documentation, guidance or error messages. A failed build's logs are part of the interface; resolving today's case matters, but removing the confusing path for future customers is the larger return.

What did the early Stripe team teach you?

The first group combined unusual craft with direct customer contact and the energy of a few people around one table. I carried its obsession with developers, polished details and excellent documentation into Render. Another lesson became an operating principle: reason clearly from first principles, then execute quickly.

What should a prospective DevTools founder ask first?

Ask why this is the problem you want to spend a decade solving. Every startup becomes difficult, so a merely attractive idea will not sustain the founder through the major obstacles. Deep care for both the problem and its users supplies the empathy and energy required to continue.

Links & references

This episode is brought to you by WorkOS.

Keep listening