Episode 101
· 40:33
Doing things that you wouldn't do if it were just a job, if it were just something that you're trying to get out there quickly. Yeah. Building in those special details that make your customers' lives just that little bit easier and helping them get by. And if they can get a little bit of joy from using your product, then why not?
Jack Bridger:Hi, everyone. You're listening to Scaling Dev Tools. I'm joined today by Anurag Goel, who is the founder and CEO of, Render. And Render is, to my understanding, is, kind of AWS, but, like, way simpler. So anything you can do with, like, AWS, but easier.
Jack Bridger:And I've tried it out, a little while ago, and it was, like, super easy to use. So it's really exciting to have you on.
Anurag Goel:Thank you. I'm really excited to be here and, talk more about what we're doing at Vendor and and about anything that, your listeners might find interesting.
Jack Bridger:Yeah. That's, very exciting. And, so I guess we're gonna talk about, to give people background, we're gonna talk about render, we can talk about developer experience, and we're also gonna talk about, your time as the 8th employee at Stripe. Yes. So Certainly.
Jack Bridger:Yep. So let's, let's kick things off, and it'd be great to hear a bit about, like, how you came to the build the idea of building render.
Anurag Goel:Yeah. So it started even back when I had just joined Stripe, 4 engineers, and one of them was dedicated to managing AWS. And as the company grew, the percentage of people dedicated to managing AWS as a total part of the engineering team continued to almost stay the same. And, in the end, you know, Stripe was spending when I left Stripe in 2016, Stripe was probably spending 1,000,000 of dollars in salary and equity for people who were mostly just managing AWS servers and helping Stripe scale. So after I left in 2016, because I'd been there a while from 2011 to 2016, it was time for me to take a little bit of a break and figure out what I really wanted to do next.
Anurag Goel:And, my goal for whatever it was going to be was to find an incredibly hard, ambitious problem that is really interesting to me, interesting enough for me to spend several decades on. And, the way I went about doing that is building applications in a lot of different domains to try to figure out if my excitement lasted beyond just the original excitement of the idea and and putting these applications online. And, through that work, I realized that, despite all the improvements in the fundamental underlying technologies of, cloud infrastructure, the developer experience was still heavily broken. I had to go through the same set of things on AWS, just to get something even moderately complex deployed. And, I wasn't able to do even, you know, a lot of the things that I was trying to do to put them online, I I just wasn't able to do on existing platforms like Heroku.
Anurag Goel:So it was pretty clear to me from working with low level cloud technology that it was time to build towards a new way of running applications in the cloud, one that allowed people to experience the power and the flexibility of, the things that the cloud can offer without them having to go build out large DevOps teams and large Kubernetes clusters and large AWS presences themselves. And so that's really how Vrndr came about, and, the company, started, in 2018. We launched publicly in 2019 at TechCrunch Disrupt Battlefield, which we won. And, and, you know, it's been, one day, one day at a time from there.
Jack Bridger:That's awesome. Was it was it, like, in Silicon Valley, the TV show, in TechCrunch Battlefield?
Anurag Goel:It was kind of like that, but with less drama. Certainly less drama. And, it was it was kind of surreal, of course, because, you know, we'd all seen the show, and we were just 4 people back then. And, just getting on stage and pitching render, and, you know, Ashton Kutcher was there and all yeah. There's a bunch of other Wow.
Anurag Goel:Yeah. So it was it was an interesting experience. It really helped, put render on the scene, certainly, and, the the interesting thing was back then, we didn't really have a ton of features. Obviously, we're talking about 2019, right, early on when we hadn't we we were just launching. But since then, we've focused, really hard on building a capable, complex performance scalable platform that allows you to do whatever you would do on AWS, but much faster, and most of it is automated.
Jack Bridger:This episode is brought to you by WorkOS. At some point, you're gonna land a big customer, and they're gonna ask you for enterprise features. That's where Workhorse comes in because they give you these features out the box. Features like skin provisioning, SAML authentication, and audit logs. They have an easy to use API and they're trusted by big dev tools like Vercel as well as smaller fast growing dev tools like Nock.
Jack Bridger:So if you're looking to cross the enterprise chasm and make yourself enterprise ready, check out Work OS. We've also done an episode with Michael, the founder of Work OS, where he shares a lot of tips around crossing the enterprise chasm, landing your 1st enterprise deals, and making sure that you're ready for them. Thanks, WorkOS, for sponsoring the podcast and back to the show. Yeah. And it's I think it's really interesting challenge that you've got where it's like you wanna make it really easy to use and, like, you know, there are tools that are, like, easy to use.
Jack Bridger:You know, I think Heroku did a good job there, like, in terms of being fairly easy to use. But then it's like you run into these limitations, and it's like you it's not really like a, you know, if you wanna do what you can do with AWS, you're gonna have to, like, migrate away from it. And so you're trying to, like it seems like a super interesting, difficult challenge to actually create something that has, like, those capabilities, but then of, like, AWS, but then is as easy to use as something like a Heroku or
Anurag Goel:Yeah. I'm Yeah. I think the core insight there was by building these applications in the cloud myself using modern frameworks and using, the latest advances in infrastructure attack, like containers and Kubernetes, it it became pretty clear to me that the industry was still operating at the level of, VMs. And when AWS came on the scene, you know, they said, okay, we're going to take your capital expenditure from the data center away and, and, you know, turn it into, operating expenses. And that was a pretty big innovation back in the day, but they didn't really change who they were building for.
Anurag Goel:AWS has always built for low level systems people, or you need to become a low level systems person to truly build things on AWS. But most of the 100,000,000 developers out there are not that, and they don't want to be that. But they still want to build applications. And as, it becomes easier and easier to build more applications online, it is the ease of use of putting them online, but more importantly, scaling them and scaling them in complexity, not just in traffic, that hasn't, changed at the same rate. And so that's what Vender's building.
Anurag Goel:And, in many ways, it's a new way to think about how to build large, complex applications on the cloud. And we've seen that happen because at this point, you know, Vrndr has, a 1 and a half 1000000 developers on the platform, and we're adding, a very large number, every month. And then we're also now focused on continuing to grow our customers. So we have customers who started out on Vendr with just, you know, spending $30 a month, and now they're spending between $1,200,000 a year. And they've grown on render, all their computers on render, the company's 100 of people, their company.
Anurag Goel:And, they love what render is doing, and our goal is to continue to have them grow on render. And there's lots of stories like that.
Jack Bridger:Yeah. So how, like because this it sounds like so so difficult. So how do you build something that is great for someone paying $30 a month and then is also great for someone, that same company when they're paying, like, 1,000,000?
Anurag Goel:It all comes down to customer focus. I know that sounds a bit cliche, but that's truly what it is. I think at Vendr, we've obsessed about customer focus from day 1, and our goal is to make sure we solve your problems in the best way possible for you. We're not trying to sell you a specific way of building applications. So we're not saying, oh, build a front end app with a serverless back end or go, you know, build your app with AWS Lambda Serverless.
Anurag Goel:We want to help you build your application the way you want to build it. We want to help you grow your infrastructure, your cloud presence, the way you want to grow it. And so when you think about problems from that lens, instead of trying to make everything fit in a box, which you see with a lot of these tools that make it easy to get started, you then make decisions, product decisions, very differently. You try to figure out what the right levers are to give people, in terms of the flexibility and the scalability that they want as they grow, and that's an ongoing ongoing discussion with our customers. And, you know, we we have, these Slack channels with some of our largest customers where the discussion is all about, like, hey.
Anurag Goel:How can we help you build the next, level of your application? And so we are always trying to be 1, 2, 3 steps ahead of where our customers are today, so they can continue to grow on vendor. And increasingly, we found that the things that we build for these growing customers are equally interesting and important for enterprises that are already large but not yet using vendor. And so we're starting to see larger companies, larger enterprises moving, new workloads to render, but also, in some cases, moving things from GCP, AWS, Kubernetes clusters over to render because they get the same functionality that you would get from Kubernetes without dealing with Kubernetes at all.
Jack Bridger:Yeah. Have you got any ex examples of, like, of how you kind of did that where someone would you know, was asking, like, how you kind of realized that a feature was needed to be built and then how you kind of built that while also, like, you know, keeping the really strong developer experience.
Anurag Goel:Absolutely. So I think it depends on, again, understanding your customer incredibly well, but not just a given customer, making sure you have a very, very clear understanding of the segments customer segments you're building for Mhmm. And how they use the platform. So there are people who want that ease of use getting started, and the dashboard is great for them. And they continue to build applications entirely through the dashboard.
Anurag Goel:They monitor them on the dashboard. But then there are folks who, for example, want, to connect privately to an AWS service like SageMaker that render doesn't offer. Now if we, had all of that in the dashboard from the get go, pretty much like AWS does where, you know, there's these 300 services that are in your face as soon as you log in, that would be very different. Our goal is, one way to think about this and and the term we often use internally is progressive disclosure of complexity. So if you don't see the complexity until you need it, and even when you do need it, it doesn't have to be through the same interface.
Anurag Goel:So you don't have to build literally everything in the dashboard if more complex customers, again, going back to the understanding, if more complex customers are able to use the API or render a Terraform provider to get that feature, then that's where you would wanna put it, instead of complicating your UI.
Jack Bridger:That's really interesting. So sorry. I'm gonna so it's progressive disclosure of complexity. That's a really cool phrase.
Anurag Goel:Of course.
Jack Bridger:Yeah. And so how do you decide if something, is, like, important enough or, like, relevant enough to go in the basic UI or if where where this fits on the progressive Yeah. Scale, I guess.
Anurag Goel:So by default, we want everything to be available in the UI. It might not be available just, like, the first thing you log in, you might have to so there's a lot of decisions we make around information architecture in the dashboard, and we're continuously improving it. So we figure out sort of what the user is trying to do. At the end of the day, you know, you map your user journeys and, you know, the product managers out there know all of this stuff really well. I've never been a full time product manager, but I'm I'm I'm definitely a product guy.
Anurag Goel:I'm a product and I'm an engineer and a product person. And and I think I've always done informally what product managers have formal terms for, and and it's the same for the amazing product people at our company who have joined, who have now taken on the mantle of the product, even though I'm I'm obviously pretty involved. So the way we think about this is what is the customer trying to do? Who is the customer and what are they trying to do? And then you have to kind of in the dashboard, at least, you have to make sure that anything, any new toggle you add, you you think really hard about that.
Anurag Goel:Like, is this actually a setting that a customer needs to see or use in the dashboard, especially? Most of the time, render is all about sensible defaults, things that you just never have to even think about. You shouldn't have to, for example, configure HTTP to HTTPS redirection on your website. It should just be there. Mhmm.
Anurag Goel:You shouldn't have to configure, compression for your application responses. They should just be part of the platform. So stuff like that that everyone kind of has to do, you make invisible. You just do it. There's no configuration.
Anurag Goel:So even today, if you really wanted to host an HTTP HTTP only website on render, we refuse to do it. We think it's insecure. Yes. I'm sure there are use cases for it because you have some clients that don't yet speak HTTPS. But you know what?
Anurag Goel:That's okay. We're not building for those clients. We're building for customers who are building with modern frameworks and applications and customers who want to build with modern frameworks and applications. And in that world, insecure HTTP just has no place. And so we just made the decision to automatically redirect HTTP to HTTPS.
Anurag Goel:And even when people have asked us, hey, can you allow me to serve pure HTTP? We've said no, and we've stuck to it. And obviously, you know, that hasn't harmed the company in sort of any meaningful way, but it has made the UI experience better for everyone else. Right? Yeah.
Anurag Goel:And so we had to take every decision, from a lot of different lenses and figure out, what the right flow looks like, how does it fit into the bigger picture. And, again, going back to an example, so you can imagine that there are certain things that people want to do through a Terraform provider, that don't need to be on the dashboard because this is configuration that they can write up. Right? So instead of just clicking through things, this is configuration, and render also has its own infrastructures code format. So, again, if you're using those things, then maybe you you're it's easier for you to apply, certain customizations that are only available through those text formats instead of on the dashboard.
Anurag Goel:So that's kind of how we think about it.
Jack Bridger:That makes sense. So so sensible defaults, and you're kind of being opinionated about, like, helping people to build modern secure applications.
Anurag Goel:Exactly.
Jack Bridger:That makes sense. And I guess that would massively reduce the complexity of the dashboard right there with all those defaults because Yeah. You just take all that stuff out the way
Anurag Goel:and people.
Jack Bridger:Yeah. And
Anurag Goel:I think that's that's often what I've seen competitors stumble on where they think that to give people the flexibility of AWS, they need to put every single feature, every single knob or toggle in there. That's not the case. Customers don't actually want it. They just want their applications to run well. They want them to scale.
Anurag Goel:They want them to be secure. They want them to be available. And so that's what we focus on instead of giving people every single little thing. And so in that sense, you know, render is really built for people who are companies, businesses that are focused on, building their businesses and their products as opposed to trying to mess with every single thing in the cloud.
Jack Bridger:Yeah. That's that actually helps me understand it way better because it's like, you know, when you when you hear, like, okay. So we wanna have the power and we wanna have the simplicity. It's always like, okay. The the power comes with, you know, like, the it's like these things are, like, almost like opposites in a sense in some ways.
Jack Bridger:But then it makes sense where it's like you're saying, okay. But we're just going to remove like, half of this power doesn't need to be, you know, displayed to you. It just needs to be, like, done automatically. So we've just, like, massively reduce the scope of configuration. Yeah.
Jack Bridger:But you can still configure all the things that actually matter to be configured.
Anurag Goel:Exactly. And so in that sense, I think, obviously, render works for maybe 95% of the businesses out there. If you're building a low level infrastructure company yourself, render is not for you because, you know, you need those little knobs and toggles. And that's where I think AWS and GCP and Azure, they continue to do a good job exposing literally everything there is to expose. And we use those cloud providers too to give our give our users the power of the larger hyperscalers, but they don't have to think about them.
Anurag Goel:They don't have to tweak anything themselves. They don't have to worry about, you know, thousands and thousands of lines of configuring Kubernetes, YAML, and looking at a 1000 vendors in the Kubernetes ecosystem, trying to figure out which one they should integrate. It's all renders an end to end all in one product that gives you kind of the best parts of the cloud.
Jack Bridger:Yeah. That that's really, really cool. Yeah. And when you talk about, you were kind of speaking earlier about speaking to your customers and, like, kind of going going with your customers, like, on a day to day basis, like, what what does it look like to actually speak to your customers? Because it feels like it's something that it's like, yeah, everyone here is, like, speak to your customers.
Anurag Goel:Yeah.
Jack Bridger:But what does it actually mean?
Anurag Goel:Fundamentally, it means having a lot of empathy for your users, making sure you understand, what they're trying to do instead of assuming what they're trying to do. Mhmm. And what that means is just continuing to ask a lot of questions, not trying to fit their needs into necessarily what you have, but thinking about what could be and how you can evolve your platform, to meet again, going back to, like, meet the needs that they have as opposed to, you know, sometimes they want a specific feature done a specific way, and you're like, well, actually, what are you what are you really trying to do? And, and so I think customer research is a, skill that everyone can develop, and, you know, I have my own blind spots there. But for me, you know, this is why I started render.
Anurag Goel:My customers are developers. I'm a developer. I love talking to other developers. I love talking about, the ways that render can help solve their problems. I love just talking about, you know, things that developers talk about because, I I enjoy that.
Anurag Goel:That's why I'm at my core. And so I think it it gives me a bit of an advantage in terms of, how I interact with our customers. And then when you look at some of the other people we've hired at vendor again, all of them have been incredibly technical even if they're not full time engineers at render themselves. They've been engineers elsewhere or in their past. They've written code.
Anurag Goel:And so they truly understand, what it means to solve customer problems through code, through the platform, through technology, and you have to engage them in multiple ways. So our customer support engineering team are so our customer support team, we we only have customer support engineers. We don't have customer support people. So every person you talk to through render support and we actually offer free email support, to everyone regardless of who they are, whether they're paying us or not. And very few people actually do that.
Anurag Goel:And the reason we do that is, again, going back to how can we continue to learn from our customers, what their problems are, how we can solve them. And it's not easy, but if it were easy, you know, anyone could do it, and and we're trying to solve a hard problem. Yeah.
Jack Bridger:Yeah. Actually, it'd be really fun to talk about the customer support because I actually don't know if we've really covered that that much. And, like, I just wondered, like, what what does it look like to, like, set up that kind of system of customer support, even, like, the kind of boring details of, like, I guess, you use, like, some kind of software
Anurag Goel:Zendesk or Infincom. Yeah. Yeah. So we it has evolved, obviously, over the years. And, I think back in the day when we started, we just had an open Slack for everyone.
Anurag Goel:Mhmm. And people would send us, their their private details in public Slack channels, and we're like, no. Don't do that. And, and then we obviously we also had a shared Gmail inbox. And when you're really small, you kind of, you know, you figure this out and it's it's manageable.
Anurag Goel:But, like I said, you know, render now has, 1 and a half 1000000 developers on the platform, and, the goal with customer support isn't just to answer their questions. It's to continue to improve self serve, help. So what that means is, if we we're we're very thoughtful now about, the kind of documentation, the kind of in product tooltips and and flows that we need that reduce, the number of, times anyone has to actually talk to us. And, behind the scenes these days, you know, we use Zendesk, but we might be, I don't know if I, if I'm spilling any any any of our beans here, but, I think we're moving from Zendesk to Intercom, because of some of the AI features that Intercom has built in that will allow us to better handle very large volumes of tickets, not by, like, giving people automated responses, but by surfacing useful information sooner. And so, you know, people talk about how AI is changing the world.
Anurag Goel:I mean, certainly, it's changing customer support, and, it's helping us be more efficient with a very small team. And, you know, like I said, we we we have a large number of developers on our platform, but we I think we only have 8 sub customer support engineers, and we're still able to offer incredible support, to everyone, not just people who pay us money.
Jack Bridger:Yeah. Wow. That's that's actually, yeah, pretty astounding, actually. Because people ask a lot of questions. Right?
Jack Bridger:For
Anurag Goel:Yeah. We also have a lot of forums. And I think when you grow beyond a certain size, then developers are familiar, with your product, and and people help each other out. And so we obviously benefit a lot from our increased scale now where when someone asks a question about vendor online, whether it's on Stack Overflow or in some community, a forum or Twitter, people jump in and they answer they try to answer because they've used render before, and that that will continue to grow. And, you know, people talk about network effects for companies.
Anurag Goel:That's certainly a great network effect for developer focused companies when people when you don't have to have someone from render answer every single thing. Having said that, a few people in the company monitor everything that is being sent said online in public forums, about render, simply because we know that that is how customers sometimes just ask for support. And, and so we make sure that if someone has a question about render online, then we jump in, give them the information that they need. And then, again, continue to improve our systems in terms of documentation, in terms of the the how the product guides you, in terms of the error messages. The error messages are such an overlooked part of any system, in terms of, you know, when your build is running and it fails, like, what are the logs that you show people?
Anurag Goel:Yeah. Like, those things make a huge difference in terms of your ex overall experience with the system. When things are going fine, everything is fine. It it it really comes down to how well the system does when when you break something in your app or your your you know? So so our goal is to focus on those troubleshooting moments as well.
Anurag Goel:How can we give you the information that you need to troubleshoot your application, in a way that gets you up and running, as fast as possible.
Jack Bridger:Yeah. And when when people are, like, doing support, I've kind of done some of this myself just, like, casually. And, like, I is it just answer the question? Is it kind of is it, like I guess it's just, like, the obvious way to do it is just, like, help them solve the problem.
Anurag Goel:Yeah.
Jack Bridger:Is that pretty much, like is there any, like, advanced, like, Jedi stuff that we we should be thinking about? Or
Anurag Goel:no. Again, it goes back to having empathy for the user, making sure that you're not, again, making assumptions about their problem. Mhmm. And I think even at Stripe, again, we were we were incredibly, focused on giving people a great experience through every channel. And so one way to think about customer support is it is part of your product.
Anurag Goel:So how would you product manage it? How would you run customer support if you actually truly considered it to be a part of your product experience?
Jack Bridger:Yeah.
Anurag Goel:When you think about it that way, then it opens up a lot of new ways to handle customer support inquiries, and sometimes even before it becomes an inquiry. Right? So so thinking about support as a product, thinking about the people who are on your team, who are who are responsible for customers, for helping customers, thinking about them the same way you think about any other engineer at the company, I think that makes it very different. That makes the customer experience very different. That's why we're able to service so many people, with such a small team.
Jack Bridger:Yeah. Yeah. And, actually, that's a good segue onto, Stripe as well. So I'd love to kinda ask you what it was like. So I guess it was it was it you were all just, like, in a room when you joined?
Anurag Goel:Pretty much.
Jack Bridger:Yeah. Patrick and
Anurag Goel:Yeah. Yeah. So, we were, in this tiny office in Palo Alto, when I joined, and, yeah, we were all sitting around a single table that it was not much bigger than this conference room table I'm I'm, at now. And the vibe was really great. I was a Stripe customer well before I became a Stripe employee.
Anurag Goel:So I started using Stripe back in 2010 when it was called slash debt slash payments. And I was one of the few people who were using it to run a real business, and, I think, well, a real business is is, debatable. It was a side project for me, but I did need payments for this side project, and no one would give me payments. They were like, oh, you need to be VC funded or, you you need to put the PayPal button on your site. And Stripe just made it so easy for me to get started back even back in 2010, that I became a fan, and then I started giving them a ton of product feedback.
Anurag Goel:And the product wasn't great back then, to be honest. And, obviously, we we fixed all of that. We launched publicly in 2011 September 2011, which was great. It was a great launch. I think it was the highest voted launch on Hacker News for the longest time.
Anurag Goel:And I think if you if you adjust for, Hacker News users and inflation, mode inflation, like, I think it might still be the the top launch on Hacker News of all time, and I'm really excited that I, I was incredibly excited, that I was part of that moment. I'd written the the Stripe tutorial, the very first Stripe tutorial that Really? Yeah. Yeah. That was one of the first things I did when I got there.
Anurag Goel:And, I was an engineer, but they needed a tutorial, so I was like, alright. Well, my job is to write a tutorial, so I did that. And, and I remember how the tutorial was the most popular page when we launched, and we were all watching the metrics on this large screen, and it was like a bunch of people sitting around a table being really excited about their startup launch on Hacker News. We had no idea it was going to become the company that it has become today. But, again, it came down to hiring the best people, making sure that we're constantly focused on customers, being very close to them, and and thinking outside the box.
Anurag Goel:I think all of those things made Stripe successful in ways that, obviously involved some luck. There's always luck with any any big startup success. But I think the team that Patrick and John built, early on, I would say that was perhaps the biggest reason Stripe was successful front weakening.
Jack Bridger:Did it feel like this is different? This is like
Anurag Goel:a incredible team? Yes. Although I will say that it was it was still just like working with, you know, any of the start up team. Obviously, the people I was working with were great. And, one way to think about how things were at the time, was to look at maybe other startups in the same space and their teams, and it was pretty clear that our team was much more accomplished and, and was able to get a lot more done, had a lot more craft, which is so incredibly important for developer products.
Anurag Goel:And I'm really just talking about, you know, the first 10 or 15 people. And, obviously, we continue to hire great people after that too. But that was a really special time. And, I think, in any company's evolution, when you're just a few people sitting around a table, there's no better time. I Yeah.
Anurag Goel:Yeah. It's it's it's so different. And, obviously, you know, the world is different now with, with hybrid and remote teams. I think remote teams can can be very effective, but it's just not the same as just, you know, just sitting around a table, just getting stuff done, and and, slinging code, talking to customers on we used to use HipChat back then, you know, talking about support tools, which was really interesting. And and I learned a lot, and I think we all learned a lot about building a company because, it was new to all of us.
Jack Bridger:Yeah. And were were there things where you were, you know, when you're starting render, you were like, I wanna take this part from Stripe.
Anurag Goel:Oh, absolutely. Yeah. So we, like I said, focused obsessively on developers and on the end user experience and on building craft into the product, on having the best documentation. All of those things were part and parcel of the culture that I knew, I had to build at render. And, the other big thing was, just thinking about things from first principles, not cargo culting, being very thorough, about your reasoning and then executing really quickly.
Anurag Goel:So, this is actually one of our operating principles now. Reason clearly, execute quickly. It's on our website, if you go to render.com/about, I think, or render.com/careers. And we still pretty feel really strongly about it because, we found that certain problems just require thinking through, at a very deep level, if you truly wanna build a world fast solution. And, and, you know, what we're trying to do here is is not easy.
Anurag Goel:And so Mhmm. We have to approach problems in ways that are that are new and unique. And sometimes the solution is out there, but, you know, most of the time, you have to kind of adapt to exactly what it is that you're trying to do.
Jack Bridger:Yeah. And I think you've said craft now twice. I I wanna actually dig into, craft because, I'd love to hear what you think that is and how you think about that.
Anurag Goel:I think craft is about, at its core, taking pride in your work and doing things that you, wouldn't do if it were just a job, if it were just something that you're trying to get out there quickly. Yeah. And what that means is building in those special details that make your customers' lives just that little bit easier and and helping them. You know, everyone's just trying to do stuff and and get by. And if they can get a little bit of joy from using your product, then why not?
Anurag Goel:And Yeah. That joy comes from going beyond, what they would expect, and making sure that you're focused on the right level of polish, and then you spend the time to make that happen. As an extreme example of that, when Stripe launched, there was a cloud on the homepage that had gears inside it. And I don't know if this was the best, thing to do, but our designer at the time spent, I think, weeks or months just building that cloud.
Jack Bridger:Really.
Anurag Goel:And, obviously, not, like, you know Yeah. Months working on just that. But, his obsession around, like, how things should look, and and how everything fits in, and the same thing applied to the API, the same thing applied to the docs, and it's the same thing for render. Like, how do things look and feel, but also Mhmm. How do how do we anticipate what people want to do, and we surprise them by having thought of it already, or we give them a tiny bit of, joy in in using your platform.
Anurag Goel:I think craft is a lot about that, but that's also at a much higher level. I think craft also for something like render, craft comes down to how do we make sure that your applications are reliable at all times? How do we anticipate these edge cases, that might cause your application to fail? And you never learn about that kind of craft behind the scenes, but that goes into what we do every day. It's not just what you see on the dashboard or on the API or the CLI.
Anurag Goel:It's also about, taking pride in building the kind of complex, scalable, flexible performance, secure architecture that powers, these millions of applications on vendor.
Jack Bridger:Yeah. That's, that's amazing. I think we've got time for just one last question, Anurag. Go for it. So yeah.
Jack Bridger:So, I mean, you've been a part of, like, a very, very early part of arguably the most successful developer tool, and now you've built Render, which is, as you said, has millions of users is, like, doing incredibly well. If you're speaking to someone who is at the beginning of their, like, developer tools journey, as a founder, what are the, like is there is there something you would say to them that you think, like, just do the focus on this?
Anurag Goel:Well, first, I would ask them why they're doing what they're doing. I think it's incredibly important to find, founder market fit. And sometimes, just because it's a good idea, it makes your life a little bit easier, and you like it at the time. Sometimes that could turn into a company, but more often than not, it's not what actually, it's not what you might wanna do over over a period of a decade. And at the end of the day, I think all startups are hard.
Anurag Goel:It doesn't matter what you're building. All startups are hard, and you really need to care about the problem that you're trying to solve to be able to sustain, the energy that you need as a founder, as a CEO, or as even as an early employee to to take the good with the bad and, make sure that you care deeply about what you're building and you care deeply about who you're building it for, and have that empathy. Because if you don't have that, you're probably going to get tired much sooner and quit when, you know, you hit your first major obstacle.
Jack Bridger:Yeah. That's, I think that seems like such good advice. Just enjoy it, I guess, in the sense of, like, they'll do something that you're passionate about.
Anurag Goel:Yeah. And if it doesn't work, it doesn't work. But at least it won't be because, because you didn't care enough.
Jack Bridger:Yeah. That's that's amazing. And so, where can people learn more about about you and about render?
Anurag Goel:Oh, render.com. And, it's it's pretty straightforward. You can find render on Twitter on x@x.com / render. Search for render on LinkedIn. You'll find us, and and you'll find us, as soon as you mention the word render, anywhere online, we'll try to find The
Jack Bridger:team is gonna find it.
Anurag Goel:Yes. Exactly. Exactly.
Jack Bridger:That's amazing. Well, thank you so much for joining Anurag. And, yeah. Thanks everyone for listening.
Anurag Goel:Thank you for having me. This was a lot for you.
Listen to Scaling DevTools using one of many popular podcasting apps or directories.
