How a Multi-Billion Dollar Founder (With 2 Successful Exits) Builds Industry Defining Products

Guillermo Rauch is a star on the Open Source scene.

In 2013, he sold two companies, Cloudup and LearnBoost, to Automattic, the company behind WordPress.

Now, Guillermo is the Founder and CEO of Vercel, the multi-billion dollar frontend cloud platform behind the Next.js web development framework.

He's also the creator behind several popular Node.JS open source libraries like: socket.io, mongoose, and slackin.

Guillermo is passionate about making the Web faster by focusing on the developer experience, so I sat down with him to learn how his distributed team builds industry defining products.

We talk about:

• How to (actually) build a really big business.

• Why you should pick a small market and dominate it.

• Why you should get out of "design land" as quickly as possible.

• How to build a culture that makes room for mistakes amidst rapid product iteration.

If you're a remote founder or product leader on a distributed team, then you don't want to miss this conversation.

You can watch it on our YouTube channel, or you can read it below.

Enjoy.

Where did the idea for Vercel come from and what made you want to work as a distributed company?

I've been involved with open source for decades. Naturally, open source is a very distributed, decentralized system, especially with git. Funny enough, I was an early adopter of GitHub when I was working with a front end framework called MooTools. Front end engineering has sort of been the purpose of my life in many ways.

Early on, I became obsessed with trying to make the web richer, more interactive, more dynamic, and more app-like. Once I got involved in open source, I decided to start a company to make the infrastructure of the web more accessible, so people would have a better, more vertically integrated, developer experience.

The distributed model has been at the core of everything we do–from how we set up our teams to how we build our systems–and it's been a privilege to get to work this way.

How does distributed work help Vercel capitalize on all the amazing creativity and diversity that comes from not being in the same room with someone?

We started Vercel in San Francisco, which gave us access to incredible investors, partners, advisors, and a receptive audience that was interested in what we were doing. People here were willing to bet on me–someone from Argentina who came to the U.S. with virtually nothing. Since I've been here, I've found community and really, it's been a place where I can thrive.

And on the other hand, with open source, I can distribute my products, my talent, and my ideas, around the world with just one hyperlink. Back when I built my first couple of projects, the only distribution I did was to blog about them and put them out on the internet, but that helped me build meaningful connections. So on a basic level, a lot of the technology that we're building right now is enabling this kind of story–my personal story–to happen again and again. It's this idea that, you're one hyperlink away from launching your next big app, or from being discovered by your dream employer. 

I'm based out of San Francisco, which is where a lot of amazing people live, but my job is to discover the best possible talent in the world and convince them to work at our company. We make massive investments into open source, so we already have this global network of people that we can tap into. At the end of the day, I think the future of work is based on the idea that it doesn't matter where you are, as long as you have the right talent and portfolio of ideas to show for it.

You're building a massive platform for anyone on the internet to use. How have you shaped the culture on your product and engineering teams to enable the kind of innovation it takes to do that?

In many ways, we're building what I like to call the "meta product company," because we're building the platforms, tools, infrastructure, and frameworks that the world needs to build the best products possible. So we're in this unique position of being customer zero for the tools that we're creating.

We've brought a lot of the innovations to the web, and an interesting one to call out is this idea that for every commit of code you push to the cloud, we give you a preview deployment URL that anyone on your team can use to see or experience what you're working on (and comment or contribute to your work). This is different from the world where developers push code, get a diff in the cloud, and then have to form an opinion on whether the code looks good or not.

Vercel really prioritizes this idea that it's the experience that matters most. If our customers are going to build incredible websites, then the way that they get there is even more important than the end result, which is this iterative process. So our product is really enabling this collaboration at planet scale that is centered around the product itself. I think that really enables a product-centric engineering culture that looks first and foremost at the user experience.

And it's kind of a paradox to our technology, because what I really posit to the market is this: start with the user experience and work backwards into the technology that supports it. To me, that's a more important insight than Next.js itself. So at Vercel, we start with what we're trying to accomplish and what we want to deliver. That's why we talk so much about Vercel enabling better performance, because we want to give you the hyperlink of the application or website as fast as possible. And that's just the starting point.

Next, we back into what kind of technology enables that kind of experience. So for us, because we focus on the front end, we created this globally distributed system that we call "global first deployment." So whenever you open a site, whether you're in SF or London, we're going to connect you to the nearest point in our network to answer and deliver that experience regardless of your location.

We really try to reuse the bits and pieces that create the back end of our technology because there is a whole suite of tools and systems that you can grab off the shelf. Instead of building a payment system from scratch, we can use Stripe. And instead of figuring out how to send emails, we can use Resend or SendGrid. This philosophy, of delegating to best-in-class components, really changes the way you build products. Instead of building up monolithically and starting every project from scratch, you build the infrastructure first and focus on the experience right away.

You talk about iterating through mistakes and successes. How have you built a culture that makes room for mistakes?

So we want to be the meta product company in the sense that we build the technology that enables you to iterate faster, discover what it is that you actually need to build, and then de-risk that solution. We serve 50 billion requests a week. I sweat through and want to make sure that our products are secure, stable, available, and fast. So it almost seems like an impossible riddle: you have to be iterative and not afraid of making mistakes, but you also have to support critical, production grade infrastructure. Now, I do think there is a technological solution to this, as a lot of what we talk about at Vercel involves leaving behind the static web in favor of a dynamic and personalized web.

The success of Next.js is actually rooted in that it's a dynamic web rendering technology, whereas a lot of other things that were competing with it were static. Now, the dynamic thing is really important because dynamism, when you render an application, is not just a way of making it faster or a way of getting better SEO, it actually is things too. One of the things that enables that to me is like a superpower–it's being able to give people different experiences depending on who they are.

So when an user logs in, we render dynamic and say, oh, you're logged in. Now, if you're an e-commerce website, you can say, oh, you're logged in, and here's the product that you're interested in. Because we know you're a returning customer, so we're not going to try to sell you a chair if what you really want is a t-shirt. Now, how does that relate to reliability, iteration, velocity, and experimentation? Well, now I can start saying if you're in a cohort of customers in a certain geography, then I'm going to try something new with you. I'm going to try to render something that is more experimental. I'm going to try to measure how you adopt it, what feedback you have, and what the product analytic events are. So that's an example of how we can de-risk and yet move really fast.

We just launched an integration with Launch Darkly where we use feature flags in combination with experiments to gate access to new innovations and things that we perceive as more risky within the company. So at any given time, when I open Vercel, I get a toolbar that allows me to comment anywhere on the page, so I can actually leave feedback to my product teams. I can see the feature flags we've enabled for new experiences and new products that are not out yet, and I can go and leave feedback on those. It's really cool.

So for example, we've built a product called Speed Insights which shows you how well your pages are performing from the perspective of real world internet users. Now we have Speed Insights_v2, and I can access that experience earlier than the world. So the pattern I really recommend to people is to launch things to your own team first, so you can get them in Prod as soon as possible. So if you have an idea, try to do the bare minimum implementation to get it into the hands of your own product team. Start getting that flywheel of feedback going by demoing it to people on real devices.

I do this with a lot of prospects, customers, and partners–right away I go into the product, open up a new experience, and ask them what they think. I tell them to play with it. This idea has become more well understood in recent years, you know, a lot of the practices that led to the creation of the iPhone were rooted in demoing very frequently. This is something I encourage a lot, and is something that our technology really enables as well (with our deployment previews). Demoing really frequently removes a whole category of bugs and issues before they actually hit the broader user base.

Are there any unnecessary processes you've rooted out in favor of a more direct approach when it comes to getting the team to go from idea to learning as fast as possible?

We try not to spend too much time in design land. I encourage our team to stop imagining stuff and to hit reality sooner. Because something could look awesome in a screenshot, but it could be a terrible product in the hands of an user. They might not like it, they might not return to it, or maybe they're just not engaged with it. This is the reality of the web, too. I always give the example of an in-app browser that opens when you click on a hyperlink from Twitter or Slack. It's different from the actual browser, and there are differences on Safari on iOS and Chrome on iOS. So in this case, you have to get to reality really quickly.

This philosophy also helps you with scope. Folks tend to underestimate how gnarly the real world is. I posited this in an essay years ago called Pure UI–the number one problem with estimating software deadlines is that we don't know what we're actually estimating. You only know what it is you're estimating when you actually understand the space of the problem. And to do that, you have to get into reality as soon as possible. And again, if you can shorten the iteration loop, if you can start to deploy more fiercely to production, and work with real data instead of mock data, then you basically get there.

You've talked about the emotional baggage that comes with fighting an uphill battle every day. What advice do you have for other founders who are in the midst of a multi-year project with no end in sight?

One of the things we did really well in the early days was that we narrowed the focus of the platform. We used to say that you could deploy anything on Vercel, but then we realized that Next.js was a front end framework. So it made more sense for us to build a Frontend Cloud than the everything cloud. Peter Thiel has a good mantra for this–pick a small market and dominate it. 

So here's how I think about this: pick a small subset of a problem–within a huge problem–and then solve it extremely well. Because the reality of the platform problem–the infrastructure problem–is that attaining high levels of reliability and quality is a multi-year endeavor. You want to make sure that you're biting off a well sized problem.

Think of it this way–when you were conceiving Almanac, and you had a screenshot of your idea, you probably thought to yourself, how hard can it be? The problem with conceptualizing products through sketches is that you don't see the depth of the infrastructure that's behind them. The only way that you could estimate what it would take to build the product is through experience or by being ruthless about how good your product is. You have to be realistic with yourself about where your product is at.

I actually just heard about a founder who shut down their startup, in what was a very emotional process, after they had been getting great feedback about the product. Everyone loved the product, yet no one actually returned and used the product in a critical fashion, so no one was paying for it. So a good heuristic is: what is a minimum, viable, critical path? For us, that was to build one great page on the internet that could go on Hacker News. A page that wouldn't go down, would be flawless, and super reliable. But to do that for just one page was a really difficult endeavor. So we started to focus on how we set goals internally.

I remember years ago, we said we were going to be the platform that loads one page in the fastest, most reliable fashion on the internet, and then work from there. So we asked ourselves what needed to be true about our company and infrastructure in order for that to be the case. We were going to be world class at that narrow domain, and then we were going to get fancier with building in API routes and more integrations.

Having a strong foundation from day one almost seems like a Catch 22. And, yeah, it was difficult to build. But a lot of people put us in production right away, gave us great feedback, and we kept iterating and iterating until we got to the point where we were proud of the foundations that we had built.

What are some non-obvious tactics that separate good teams from great teams?

In the early days of Vercel, I would look at customers and say, oh, this person is really influential and oh, this person works at this massive company. Then, I would ask myself what it would take for them to use Vercel at their company instead of on their side projects. So I would qualify their feedback and how it would represent the future of the business.

Another thing is to be very ruthless about use cases. Our platform got a ton of usage for things that were not conducive to building a big business. And over time, we had to say "no" and de-prioritize certain things. Sometimes you're just so eager to please everybody that even if you have 100 issues, you want to solve them all. But sometimes, you should only fix one. You have to be willing to say, this is not what my product is for.

Some people have this dream of creating a massive company, and they think, well, if I'm going to build something the size of Apple, doesn't that mean that I have to please everybody because I'm going to sell to everybody? The answer is no. That's the opposite of how Apple was built. Apple was built by saying no to a lot of trends, use cases, and customization options that they disagreed with. That's how you actually build something excellent.

This goes back into somewhat of conventional advice, but it cannot be understated: you have to be saying no a lot, and it's painful, but you have to seek it. The other one that I would call out for the world that we're in today is that hopping on the right waves matters a lot. When we started Vercel, I got lucky in that I picked the right wave, which at the time was React. React was really small, and was a controversial project at the time. I built a framework around it and essentially bet on it being a trend. And then when I said we were going to build Next.js, it was predicated on the bet that React would get really big. I bet on React being the right answer, or part of the very small subset of right answers to the problem.

Now, if I was starting a company today, I would probably bet on AI. But not just AI in general. I would have to pick one horse–the React horse, so to speak, in the AI space. While I can't tell you what horse that is, I can tell you that there's certainly a lot of tailwind in that space, and that it is the right wave to hop on today.

What's one thing you know now that you wish you'd known when you started your first company?

One thing that I under appreciated was the compounding value of delivering great product improvements every single day, every single week. A lot of our most faithful customers report that they love Vercel, but they don't mention specific things. We hear a lot about the brand value. We hear a lot about our design. But what we look for when we build products is feedback like the following:

"Every time I create a new product or have to make changes, it feels as smooth as butter. Thank you so much for making my life significantly better and coding so much more fun."

There isn't a particular feature that generated this kind of reaction. It was really due to the compounding effect of iterating and iterating and iterating. If you pick a decently sized surface that you can go after, then you're going to realize that you now have a space to delight users and create fun, smooth experiences. So really, it all starts with surface selection.

If I could go back to those early days, I would have constrained the surface of what I was trying to build so I could get to that end result faster.

Next Week on The Big Bet: Job van der Voort, Co-Founder and CEO of Remote

Job van der Voort is the CEO and Co-founder of Remote, a global HR platform that helps teams around the world manage payroll, taxes and compliance.

Prior to starting Remote, which was recently valued at over $3 billion, Job was the VP of Product at GitLab, the world’s largest all-remote company. While at GitLab, he helped the company hire talent in 67 different countries, grow from 5 people to over 450, and reach a valuation of over $1 billion dollars.

Job is an expert on all things remote, including scaling remote-first startups, building remote culture, and working as a distributed team. My full conversation with him is coming to your inbox next Thursday.