How Vercel found extreme product-market fit by focusing on simplification | Guillermo Rauch (Vercel's CEO)

Todd Jackson: So Guillermo, welcome to the show.

Guillermo Rauch: Hey, thanks for having me. Excited to be here

Todd Jackson: Let's go all the way back to your earliest days as a programmer. How did you get your start and what drew you towards web development?

Guillermo Rauch: Yeah. So I grew up in a suburb outside of Buenos Aires in Argentina, and not a ton of people had computers at the time, especially my neighborhood, but my dad brought a computer home. And the thing that he challenged us to do, me and my brother, was what can we do with it? How can we hack it? How can we install software?

How can we do more with it? How we can, how can we experiment with it? Get this sort of very scientific, experimental mindset about it. And uh, yeah, I taught myself how to code. Growing up in a pretty poor area of Argentina. One of the things for me that was really a key enabler of my career was Can I make money from the things that I do?

Can I, can I code and, and provide services on the internet and things like that? So I started my first business when I was 11 years old. I ended up dropping out of high school found my way to the Bay Area where I started a company that I later sold. And yeah, so it's been a, it's been a wild journey from, from the early days, but really the enablers for me were open source and learning to code and, uh, teaching myself how to code and teaching myself English.

Todd Jackson: Did you get kind of into the open source community in those early days?

Guillermo Rauch: Yeah, so one of the key things was at the time, I'm 11 years old in Argentina, there aren't a ton of resources, very few guides on the internet for the kinds of things that I wanted to do, not a ton of them in Spanish also. And my first breakthrough, I would say, was I started trying really hard to learn how to replace Windows on our home computer with Linux.

My dad kind of like came up with this idea because he bought a magazine at a, uh, at a magazine shop that said like, Linux free software and brought it home. And, and again, he challenged me to try it and, and replace Windows with Linux. It sounded cool at the time, and I remember Linux was really hard to use.

Uh, I started with Red Hat. Red Hat's claim to fame at the, at the time was, it's an easier Linux to install and use. It was one of the first distributions of Linux that had a GUI based installer. And out of the box, you would get X11. And I can't remember if it was like, I believe it was KDE or, some visual environment at the time to make Linux more approachable for desktop users. And then I quickly got into, okay, like, I don't like Red Hat anymore. I'm going to try to use Debian, which was the more hardcore version of of this distributions of Linux, it really was challenging, like compiling things from scratch, even just like making, you know, the accessories of the computer work was challenging, and I found the community online in this IRC chat that was attached to my Internet service provider at the time, and they had a Linux channel, and I started getting in touch with the community of enthusiasts in open source that really it just changed the way that I thought about software development, I got that sense of like, I can learn together with others, we can exchange information, we can exchange best practices.

I got really deep into internet forums. And one of the key breakthroughs was when I discovered this world of open source software that I could download, fork, contribute to, and build a career out of. So very quickly after that, after sort of mastering Linux, I got really seriously into programming and I started discovering, open source software like WordPress, uh, open source software like Symphony.

And for me, the key breakthrough was when I started contributing to this project. So one of them was called MooTools, MooTools was this UI library was trying to revolutionize how front-end worked in the web browser, making it more interactive, making it more real time and through MooTools, I kind of built a online career and started getting reached out to from lots of different places, companies that wanted to use MooTools, in production.

Open source really was my path out of Argentina in the end.

Todd Jackson: And what was motivating you? Was it pure curiosity and kind of tinkering? Or was it kind of, you know, the feeling that you could make a career out of this?

Guillermo Rauch: It was kind of both. So in the beginning, one of the things that really, helped me a lot was I started teaching people. Everything I would learn, I would try to write a guide. I would try to explain to someone in a forum. I would try to earn internet points. I remembered this community that had like a leaderboard of who was answering the most questions.

And then one time I randomly met a stranger was like, Hey, like you can actually use the all this knowledge that you have to like, make changes to systems and, and get paid for it. So that was kind of like my, I was, I was like, I think it was like 11 or 12. And I started combining this sort of like, okay, I can actually make money from code.

I can contribute to this projects and build a career out of it. And the thing that it correlates with is the thing that I was most passionate about, which was making UIs faster, more dynamic, more real time, also started getting more and more prominence in the world. At one point, Facebook in the early days reached out to me because they wanted to hire me.

I was still a teenager in Argentina. Because they were like, Hey, we're investing really heavily in this. We like what MooTools did that project that I was contributing to. It's super aligned with how we're approaching what at the time was FPJS or internal tools for building. I mean, some of the most visited, most, uh, successful front ends in the world, like the newsfeed and Facebook chat, uh, and they were interested in hiring me. And I started realizing, Hey, there's something really substantial here. This specific area of technology that I'm choosing to focus on is really taking off. So that's when like it really became self evident.

I remember also I would create these demos that would make it to the front page of DIG at the time and read it. I was becoming like a five minute internet celebrity. Every time I would create a really cool demo using this front end technologies.

Todd Jackson: Very cool. So take us back to your first company, CloudUp, which I know you eventually sold to Automatic, the makers of WordPress. What year was that? And what was the idea?

Guillermo Rauch: Yeah. So, this was about 2013. I had already been working on this company for, for quite a while in my first startup. One of the things we realized, so in the beginning, this company was focused on EdTech. And it was a very, very broad platform with really, really, really big ambitions. Uh, we realized later on that we should simplify the offering.

We should really focus on. One thing that we could do extremely well that could impact a very large number of people. So we pivoted that EdTech startup into what became CloudUp. CloudUp was an early inspiration for Vercel in many ways because one of the killer features was you would get this application that sat on your menu bar.

You could drag and drop any file or even a folder of files. And it would immediately give you a hyperlink back, it's the easiest way to share anything on the internet and collaborate with others. And one of the killer features was you could actually drag and drop a folder of files. If those files were HTML, you would get like really fast, really high performance, as static hosting.

It's kind of like an emergent feature. So we had a private beta going on and before we opened it up, I showed it a bunch of people. And because of open source, I had already been connecting with the founder of WordPress. I had reached out to him many years before talking about front end performance and how some of the new techniques that I was developing with JavaScript could really speed up, uh, WordPress themes and things like that.

And when I showed him CloudUp he was like, Hey, like, this makes a ton of sense in the context of, of WordPress because we're investing really heavily on, on, modernizing the front end layer, which we had become experts in, and we're really interested in the real time technologies for collaboration so that you could go to WordPress and like edit posts, what later became the foundation of their block based editor for WordPress five. And it kind of made sense. We ended up selling the company before even, uh, we opened it up to the public. At the time we had been working this for quite a while and we were so aligned, I think philosophically with how WordPress, uh, thought about the future and to me, I saw the huge learning opportunity ahead of me.

I was really, really interested in the open source world. And I had already seen that WordPress is actually building a business. from their open source beginnings. So it ended up being an awesome collaboration that I spent two years there working in a variety of really interesting projects. And then that gave me the right foundation and inspiration to then work on Next.js and Vercel.

Todd Jackson: So what were the biggest learnings from CloudUp or from the couple of years that you spent at WordPress?

Guillermo Rauch: So number one, um, before CloudUp we're trying to really boil the ocean. We're trying to like create so many features and it was like a plethora of products that we're offering as a platform. And then when we actually would go to users, we realize, Hey, like this, this one a specific feature that I like the most.

So at the time, uh, folks in the education space were using this file sharing capability to share lesson plans.

And then we realized, Hey, like this idea of like creating this units of collaboration that are focused on speed and traversing all the different points of multiple devices, multiple social networks, multiple collaboration platforms.

We saw a great opportunity to simplify there and create a product that was really high quality. That I could sit down with anybody and show them it and end to end everything would go great. It would be reliable. In 30 seconds, I could show you the value that it created. It didn't require a lot of storytelling.

You could just see it. Uh, it was inherently collaborative. It taught me about the, what I call now the unreasonable effectiveness of URLs. So when I give you a URL, you can share, you can embed it in any system. So much of what we help with the development process today with Vercel for our customers is that for every single change that they make to their front end code basis, we give them that URL that they can share.

It's very similar to what Google docs did for word processing, similar to what Figma did for design. So it really inspired us to think about like what can the web do better than any other platform? And then I think on the, on the company building side, I think it taught me about the, that, that idea of like focusing and how important it is, especially in the early days of a company and how easy it can be to like slowly let go and just like overbuild.

So going back to our foundations and going back to like the simplicity of that product. It's what made us succeed to the point again where we, we had a successful exit.

Todd Jackson: So, Guillermo, tell us the founding story of Vercel. It sounds like you had been cooking up some of these ideas while you were at WordPress. When did you decide to leave and when, what was the beginning of Vercel?

Guillermo Rauch: Yeah, one fun fact is when I first came to the Valley, I became one of the earliest users of AWS. And I love that idea of like, I mean, it's just magic that like computers are in the cloud. Hardware became software. Like it's just so abstracted out of the air. There's robots moving hardware around in racks somewhere.

And I just don't see it. I make an API call. Now we have that foundation of magic in theory, but then when you actually use it, it's freaking hard doing anything with a cloud. It was so freaking hard. I saw that at WordPress again, because at WordPress they had invested millions and millions and millions of dollars in becoming proficient at hosting one application, wordpress.com. But any incremental new app, new product, new feature was very, very tedious. It was, it was hard to get that freedom as a developer. I had so many ideas. I wanted to try out new frameworks, new front end solutions, but I was sort of constrained within the confined of a monolithic solution, but that's not to say that WordPress did it that way.

At the time, the entire industry was primarily this monolithic architectures. What do I mean by monolith? Everything is in one place, everything is in one code base, the database and the code are very intricately tied, and the world is starting to move in the direction of microservices and composability, breaking down these monolithic ways of building.

And the promise of doing that was that developers would get a lot of flexibility. So it's like, okay, but that's that's awesome. That's what the cloud promised me, the cloud promised me that I was going to be able to move really fast. And I was like, okay, like everything I can see around me has not really fulfilled that promise.

So I left with this idea of, okay, I'm going to make deploying software completely instantaneous. And I'm going to give that power back to the developer. So left, basically my main thing was like, okay, I'm going to adopt food from day one. Another very important lesson from the cloud updates. I wanted to build a tool that I was going to use every single day to make my own tool better.

It was going to be fractal. It was going to be recursive.

So I left and started doing that. So, okay, my first task, I need to create a website for my company. I knew that I didn't want to use the Squarespace because I wanted to build a production grade stack that was extremely dynamic. In my mind, I was going to build, you know, something of the complexity of AWS.

With a marketing website of the complexity of any enterprise marketing website today. So I started building with the best practices available at the time. React, and I was going to create this deployment platform on top of Kubernetes. Just the first three four weeks of trying to put up a website online confirmed all of my previous hypothesis of, holy crap, how, how have we made the cloud so hard to use?

How have we made the simple thing of, the simple act of putting up a new idea, a new website, so difficult? Even though, again, there's this tale of two cities of best of times, worst of times. Because I'm using React which is the open source framework that, uh, meta had just open sourced, that they had been using to build some of the most dynamic and complex front ends in the world.

And the same with Kubernetes and Google. So to me, I remember thinking at the time I was in my apartment in San Francisco, if I'm struggling. Imagine the next 10,000, 100,000 companies that are going to go through digital transformation. I'm not even talking about like hot Silicon Valley startups, of which many are our customers today.

I'm talking about the e commerce players of the world that are transforming from brick and mortar. And they're trying to get a solid dot com that's really good, that's competing with amazon.com. Those folks are going to need the most help in really being agile in the cloud. So that was kind of the genesis story.

A lot of the initial hypotheses were absolutely correct. But getting there, getting to fulfilling that promise is actually a lot of work. And open source with Next.js ended up playing a really big part of that, of us finding that success.

Todd Jackson: It sounds to me like so much of this was driven by your personal experience, right? You bringing up the website and seeing how hard it was to do that. How much of the initial ideas for Vercel came from your experience or the developers and other people you were sort of talking with and hearing their pains and their frustrations?

Guillermo Rauch: Yeah, that's where I think the, the opportunity to sell our company was actually, uh, in some ways I was like a little sad at the time. I was like, Oh, I'm letting my baby go and it has so much potential, et cetera. But seeing, I think firsthand some of the challenges that developers have at large organizations was super useful, especially the successful organizations.

WordPress is incredibly successful. So like, you get really interesting inputs from that because those then later on become your highly qualified enterprise buyers, right? Like, you actually sell to very successful businesses who have the capital to buy very innovative technologies, right? So, that was super useful.

I think that my personal, uh, experiences, incredibly useful because it's a classic story of like product led growth, right? You use open platforms like GitHub and GitLab, and you have all these marketplaces of integrations and you use the public cloud. And so you have access to like cutting edge technology.

So you can put yourself in the shoes of someone that's trying to integrate all of these great technologies. And I think it's in the integration of all the moving parts where a lot of the opportunities arise. And the other thought that I had at the time was, yes, I'm just creating a simple website for myself.

Large enterprises are not creating simple websites for themselves. But I challenged myself to create a framework, and this is what Next.js became, that could be really good when the project is in the early days and is very humble, but it could scale really well to lots of complexity. And that required, I think a little bit of like that intellectual inspiration and challenge that I created for myself.

In 2014, I had written this article and I highly recommend this to prospective founders. I wrote this essay. Called the seven principles of rich web applications is the first essay on my blog. I think this was, uh, right, right after I had sold the company. And this kind of became my blueprint for the entirety Next and Vercel, believe it or not, like just me sitting down enumerating the seven principles.

I didn't have a frame. I didn't have a technology to like turn these principles into action. But it kind of became the master plan, like when you read the Tesla master plan, it became a very thorough, uh, master plan for what later became Next.js. Uh, and one of the key insights there is that I kind of reverse engineered how Google was built, Google search specifically, how Facebook was built, how Amazon.com was built. And I thought to myself, Next.js should have no compromises. It should be able to, of course, build a little website, but I want to put it in the hands of someone that's building the next Amazon.com, the next Google.com. And just setting up that really high bar gave me that direction, uh, to be able to build something that over the years, you know, we've obviously raised a lot of funding, we've hired tons of great engineers to work on it.

Most of my original Next.js code is deleted now, but it gave me that really high bar, uh, and that ability to make a lot of incremental progress against, against it.

Todd Jackson: Okay. So you had all these, these big ideas, these problems you wanted to solve. You had the seven principles. What did the first, the very first version of the product look like? Like what were those first, you know, three months, six months looking like to get to the V1?

Guillermo Rauch: Yeah, something we did early on and say we had the time, I think it was just myself still at a time, uh, or I was in the process of onboarding our first two, co founding engineers. I said, I'm going to put out a prototype of the deployment platform in three months. And I'm going to announce it publicly to start getting feedback.

Creating infrastructure like that in three months is very, very difficult, but I wanted to create a deadline for myself to start getting feedback. In the process, we kicked off, okay, like a deployment platform needs this dynamic web application to be able to like orchestrate to see logs to like all the things you need for a platform like that.

And that's when I started working on this framework, which at the time was internal. So one of the big lessons here, and this, I think, is one of the key insights that led to the success of Next.js, is I created a framework, a dev tool that had an initial, very interesting initial use case.

When you look at programming languages that have been successful, very often they have the same dynamic going on.

You look at Rust in early days, it had Servo, which was the rendering engine that Mozilla was working on, and a bunch of other very, very interesting, demanding projects as their customer zero. So I worked on that V0 of, of the deploying platform and concurrently started working on, okay, like we need to actually put React in prod.

We need to make React fast. I knew I wanted to use React it had kind of like change the way I thought about UI components and programming at the time, but I saw this huge opportunity to like, actually the way that I explained today is that really it was a great engine. And I needed a car to get from point A to point B.

So we started kicking the tires on this tool. At the time we called it N4. It was internal. And every day we're like, Hmm, like this is working really well. We're moving really fast. It's giving us, uh, the results that we wanted. And then, like, let's call it, like, six months later, we're like, okay, there's something really interesting here.

We need to open source this. And I tell people, like, it felt like it became a little bit of an overnight success because it had a lot of attention and a lot of adoption since basically day one. But they hadn't seen all this development before, they hadn't seen all this internal battle and pressure testing. I had been thinking about the principles that the framework would live up to. Since like two years prior or even more. So there's a little bit of the overnight success myth there. Um, but it was in many ways, and this is also what I encourage folks to, when, when we're trying to ascertain product market fit, when the product does still have a huge pain, you do see pretty fast adopt- you see fast growth almost right up, right out of the bat.

The key thing is that it's sometimes hard to identify, it's obviously hard to get there. But when things like fall into place, you do see fast growth.

Todd Jackson: You mentioned that Next.js was popular basically the day you launched it. Um, talk us through those first few weeks of, of launching Next.js and, and kind of the usage that you started to see and, and maybe some of the community that you started to see develop around it.

Guillermo Rauch: Yeah, there were some very interesting signals right out of the gate. One that I would recommend people pay attention to is when something is really needed, there's lots of very intelligent people at other organizations probably building a version of it. So I remember right, right after we released it, someone from Redfin reached out and they were saying, we're building the same thing.

And then a week later, someone from Trulia reached out. Oh, we're building the same thing. So I got all these people saying like, especially not just, you know, folks doing like little experiments or folks running businesses at scale saying, I'm either building a version of this or just about his staff again is building a version of this, uh, or we're looking to share ideas and best practices.

How do you solve this problem? How do you solve that problem? So, to me, the most important signal was seeing that at the time that I released it, I had quite a bit of a following in the developer community because of my work on MooTools, Socket.io, Mongoose. So I could get folks to at least look at what I was going to ship, right?

Like developers, I wanted to hack on new things, et cetera. But the corresponding signal of larger organizations could see a lot of value from this was what really made me extremely bullish on the project, especially because we had certain key features like server rendering. That in some ways kind of went against the popular narrative at the time.

Everyone's excited about doing all of the rendering on the client. And I mentioned, I remember reverse engineering Amazon and Google and Facebook. It was like, wait, this, these folks are not doing it that way. There, there must be a good reason for performance and scale and privacy and many other things.

Uh, so it was interesting because for a couple of years, we had this almost competing signals. Larger folks, super excited about it. Not everyone in the developer community was just, and there were some competitive alternatives at the time that had a completely different philosophy. So we did have to navigate, it wasn't like this obvious, we've won right away kind of thing.

We had to navigate the market and the competition for, for quite a few years.

Todd Jackson: That's interesting. So where were you sort of getting the pushback from developers or where were they finding things that they didn't, that were, that were foreign to them or that they weren't quite sure about?

Guillermo Rauch: The, the framework that I use today is developer experience at all costs doesn't work. It's bad for the, for the vendor startup enterprise, it's bad for the developer because at the end of the day it's like the good old adage of the customer is king. We all get paid. You, me, like every vendor, if the end user has a successful interaction with someone's business, they're signing up, they're happy, they're returning, they're loyal, they're not abandoning carts as we call it in e commerce.

Uh, the average order value goes up all this good things that happen to businesses, right? And sometimes this is the paradox of developers is sometimes as developers, me included, we do things that might sometimes be more of in our own interest.

whether it's an easier solution, better developer experience.

Whatever, like I just wanted to ship it and that'd go against users. And I think, with Next(.js we really worked hard on finding that balance between developer experience and user experience, because I was thinking about those businesses at scale. Not everyone in the developer community was super sold on that, not because they said users don't matter.

There was a lot of optimism that certain things that were really good developer experiences for whatever magical reason, let's call it Moore's law, or just hopium. They were like, okay, the user part will figure itself out, you know, fast forward a few years, the user part never figured itself out for those solutions.

And we did have to invest in a very rational, balanced way. And that's what ended up ended up helping Next and solutions like it win.

Todd Jackson: Can you think of an example of the developer experience versus user experience trade off and how you sort of navigated that?

Guillermo Rauch: Yeah, I can think of plenty. In fact, I have seen versions of that in the AI space now where you're able to have a great experience in building a very simple system. Think of it as like the distinction between like single note systems and globally distributed systems. It's actually quite easy to, you know, for example, like self host next JS is all you're doing is serving a limited number of users in San Francisco.

Most of our customers have global customer bases so when you deploy, we actually have to do this very careful, large orchestration of services across the entire planet. And this is well known in computer science theory, the distinction between a single node system and a globally distributed system, it actually makes for a very, very difficult and different side- uh, set of design trade offs and engineering trade offs. I see that a lot where, like, I put out a GitHub open source project. It promises the world. It does have a verifiably good experience. And it's just limited to, like, day one in your own laptop. The moment that you need the recipe for, okay, I'm going to have a million users.

Or I need to deploy it. It needs to scale. It needs to deal with the complexities of the real world. Like, networks are always failing. Things at a global scale are actually more, more often than not in a partial state of constantly recovering than perfectly working. And, and a lot of folks are just not tuned in to that insight in, in the early days.

So like, maybe they oversimplified the design, but that overly simplistic design can have an extraordinarily good developer experience. Because they actually created a simplistic solution to the problem as opposed to a simple solution to the problem. And yeah, so it's, it's, uh, it's a careful balance. Some of those systems can successfully navigate away of the initial design and become a little bit more sophisticated and complete later on.

Some actually end up finding a local maxima. So they actually never progress beyond that initial excitement. Sometimes we use the framework internally. We call it like day one versus day 1000. It has to be good at day one, but never at the expense of day 1000. Day 1000 has to be secure. It has to be debuggable. it has to be operating at a global scale.

Typically we're talking like lots of different nodes across horizontal scale. So this is very much in the space of dev tools and infra, but you start realizing the marks of, of what can work at the different scales. Now, what I'll say that I think is really interesting is, there is systems that are on the other side of the spectrum.

That they only work at gigantic scale, and no one has actually put the effort to try to create a good developer experience. And folks, then, the sort of false dichotomy mythology builds up in people's minds. Oh, if there is this really complicated message broker queue orchestrator workflow system. Yeah, it's really hard to use.

And it must be hard to use because it's solving really hard problems. That's actually not the case. Like, you can do both. And that's where a lot of the opportunities, I think, in recent years have come up. Most recently, I remember, uh, there's this company that is creating a faster version of Kafka. And they were just saying, I think there's a good parallel here.

I think it's, uh, they're called Red Panda. They were saying, I'm faster than Kafka, which is what a business wants to hear, higher efficiency, lower cost, etc. And the developer experience is better. There's a single statically linked C++ binary. It's easier to work with it on your laptop, lower memory footprint.

It's easier to deploy. It doesn't require this extra infra in Zookeeper. So there's a better developer operator experience. So it has good DX and good, like, let's call it UX or like business value on the other side. So you can have both.

Todd Jackson: So Next.js and Vercel, I would say had such strong product market fit pretty much right out of the gate and you know how rare that is, how hard it is to get that right. Is there anything, you know, and I'm thinking of future founders here, is there anything we can kind of reverse engineer from what you got so right and found product market fit so quickly that you think is applicable to other founders in their journey?

Guillermo Rauch: Yeah, I'll tell you one of the catalysts for that joint product market fit was us simplifying the offering going back to like the CloudUp of, uh, understanding. At the very, very beginning, the very first prototype of my deploying platform, it was focused on deploying absolutely everything. And if you can deploy absolutely everything, you're going to have such a surface of complexity that are going to be as complex, as the most complex thing that can be possibly deployed as a platform. So there is no sugarcoating, right? It's, it's, your lowest common denominator will be Oh, I have this Java backend Docker container that I want to deploy. And it's like it requires 20 gigabytes of memory for whatever reason, and like, we dealt with that problem for a while.

And then we said, we had this like, finding ourselves moment of, we're, we're making front end engineering better. We're making the front end facing part of a website better. Our earliest customers and design partners are in the e commerce world, they're creating store fronts , we're giving people the best react experience.

So why are we trying to like, you know, make everybody happy if there's a huge market, literally every user interface on the internet could be on Vercel. Why don't we simplify the offering? And we started focusing more on the front and then we built the front end cloud. In the beginning, we're more like we're building the cloud.

So I think that simplification and focus, it also resonated immensely with customers. Because the last thing an enterprise wants to hear is, Oh, here's a thing that does everything and promises heaven. It promises that it can do, solve every, every single one of your problems. Folks are just so tuned out of that narrative.

It's much better to say we do not solve that set of problems. In fact, we integrate into solutions that maybe you just bought before this call. So the integration into the ecosystem into what enterprises were already procuring became a strength rather than a weakness. And that's especially true if you want a reverse engineering product market fit.

You're bringing a new solution to market. The average count of SaaS software enterprises bought is like a thousand. Your strength can be in what you don't build and what you integrate with. And the other thing that I underestimated in the early days was just how much value can be accrued in having exceptionally good integrations.

For example, our GitHub and GitLab integrations. I've seen probably tens of thousands of developer hours in fine tuning, retuning, optimizing scaling, because one of the ways that people get to know our platform is they link their next project, the repo, they link it to Vercel and then for every commit, we build it. We give you a URL kind of back to like the cloud updates. For me to get to that point where I can very easily hop on the thing that you already use. That was a key, that was a key unlock for our growth. Instead of saying, oh, by the way, we also have a good hosting service. By the way, like, please use ours.

And believe it or not, that's a trap that founders can fall into. That say... instead of integrating, I'm just going to try to like boil the entire ocean. I would call it the unreasonable effectiveness of building a lot of your engineering into the quality of the integration.

Todd Jackson: So you've mentioned this idea of the front end cloud, and I love this idea, the surge of the front end cloud. What is your perspective, you know, based on what you've seen sort of on the ground building front end products over the last five years, 10 years, what is happening in this space of front end engineering?

And how does that get you to the front end cloud?

Guillermo Rauch: Yeah. The biggest shift, which I kind of alluded to earlier is a shift from a static to dynamic. So if you look at the history of software on the web in general, those that's had tremendous problems, just even keeping a website online. I tried to go to a concert the other day and just getting the ticket was giving me errors.

Like, I was like, this is 2023. We have this incredible AIs and reasoning machines that are like an API call away, and I cannot get my ticket to go to this concert. How do we get here? We got here because we have this piles of monolithic software. When we brought it online, it saw a tremendous amount of load that was unexpected.

It was very hard to modernize. It just moved all in one piece. And even if you try to keep it online because you're under attack or whatever, the only solution that people have, the huge hammer that people have is caching it in a CDN, literally making your website static. What do you lose? Well, you lose the ability to know who the user is.

You lose the ability to know what recommendations they care about. A lot of our customers come to us because they even lost the ability to remember if a user was logged in or not, believe it or not.

So we're trying to unwind that mess of the entire internet is either static or down, and we're trying to give them a path that's incremental.

So I'm not asking you to rewrite the entire world. I'm asking you to modernize your front end. You can even keep your back ends and that, and that's why you see that incremental journey. And now, by the way, you free yourself up to grab a lot of this back ends that are off the shelves. So you don't have to reinvent every wheel.

So the front end cloud is rising in the context of this composable ecosystem of APIs. You have Stripe for payments. You have Twilio for communications. You have DMSs that are now becoming APIs rather than this monolithic platforms. And most importantly, you have AI. With the rise of this reasoning as a service machines, you can now sort of dynamically render pages.

You can compute content on the fly. But again, for that, you need a very dynamic platform. So, Next.js and Vercel have sort of become now the standard for solving this problem. ChatGPT itself is built on Next.js. A lot of the generative AI companies are betting on Vercel to be their web infrastructure because of this need for dynamism.

And the ecosystem is also coming along. So Shopify is going headless. A lot of our customers are using Salesforce commerce cloud are going headless. So it's not just a one off. It's an entire industry is sort of saying, I do my job best by giving you this API. And for aspiring entrepreneurs, that means that you can join this ecosystem.

By simply providing one specific service and if you have integrations into the front end cloud, now you've put it into the hands of your customers by basically giving them a React component. So it used to be that to integrate a new service, you had to like follow like 10 pages of documentation.

In the front end cloud, the key primitive of collaboration between services is here's the UI component. And that just brings the ability to bring new products to market.

It's just, it's just incredible. There's a company called Clerk, for example, is doing this for auth. There's a company called free gate that's doing this for in product tours and onboarding. there's a company called Recent that is doing this for email that builds on top of react components. So it's really exciting.

I call this the Lego bricks for adults in order to integrate into the front end cloud, you just give them this Lego brick and it just clicks on top of the platform.

Todd Jackson: hmm. And hearing this makes me wonder, you know, over the last 20 years or even going back further than the than that, there has been so much focused on back end and there are a million databases and data infrastructure products. Why do you think people are now paying so much attention to the front end?

Guillermo Rauch: I think that makes sense because it was a starting point. We needed to build the foundations of the cloud on top of which we're now able to have this luxury of building this high level clouds, right?

So we need to lay out the foundations of compute, the foundations of data, the pipelines to connect the systems, the service meshes. And luckily, now we come in and feel to abstract all of this away. So it's really hard, I think, to make a dent into this ecosystem by saying, all I have is this low level data service.

That's why you're seeing that the new companies that are being successful in this space are actually going higher up the stack. They're saying, oh, don't rebuild your login screen for the thousandth time, oh, and by the way, you're likely to get it wrong because the space of permutations that exist there is incredible.

So you need to have all this, you know, thought into the end user experience instead of worrying about like the computational complexity of whether my database query is O1, ON, or ON squared. I think we're changing the dialogue to be more productive, more customer focused. And that to me, going back to that initial dream that I had of the cloud, that's why I signed up for Team Cloud.

That was the whole point. Great products, great customer experiences.

Todd Jackson: Let's transition and talk more about open source. How have you thought Guillermo about kind of going, uh, going from a successful open source project to a successful business?

Guillermo Rauch: I have a very simple framework today. We have to align the value creation of open source with the value creation of the business that supports that open source project. Uh, a lot of folks initially when they get to GitHub and systems like it, they look at the number of stars and they're like, cool.

Another very important signal is how frequently the project gets deployed or, or updated. What is the commit activity? Are the tests green? Is this seeing investment? So at the end of the day, the customer of an open source project wants to see continuous investment into the project. They need to be able to make a bet.

That's at least for the next 10 years, especially when you switch platforms, how do you do that as a business? There's not a ton of creativity there, right? Like you either go open core, which is like you basically limit features or you, or you use some kind of license that that allows you to like give features, but sort of constrain how they're used and deployed.

And then that gets into like a contractual relationship with the user. Or in our case we developed an infrastructure business at a global scale that aims not to just host the product, but entirely outsource teams worth of responsibility for the companies that use our system. So it's a very simple equation on the infrastructure side for the company to say, like, do I stand up a team of like five, 10, 20 people? I had a customer in Japan recently give me back a presentation of how many engineering resources they were able to redirect from platform engineering to product engineering and data science, because they were like, okay, we've freed up the infrastructure resources of our company to be able to create customer value and customer insights instead. So, that's the other type of business that you can build with open source that I think over long periods of time, as the company gets more, gets better at evolving its own infrastructure, it's very hard to compete, I think, with, you know, if I use MongoDB, I'll be the first person to recommend to my team.

Let's give Mongo to the experts of hosting Mongo. Uh, let's, let's give it to the clouds. Let's give it to the folks that have been hardening this system at scale. But it gives me confidence to know that if I have the optionality, I'm betting in an open platform if I decide not to do so. I have the freedom to take the workload with me.

Which is why I think open source is, in my opinion, the global maxima. Because if there's a company supporting it, I can automate a lot of my undifferentiated work away if I'm a company. And for whatever reason, if I need to do it on prem, I also have that option having this duality with only proprietary software ends up being quite challenging.

You really actually just locked into a single vendor. So my preference, if I were to do it over again, I would do it the same way and I would continue to invest in making the product as free and available as possible.

Todd Jackson: And then how did this thinking translate into your early pricing? Like, how did you think about charging for the product? What to charge for, how to charge?

Guillermo Rauch: Yeah. So initially we were very focused on the infrastructure. So we're like, okay, like how can we meter based on every ounce of traditional resources that you would think of are needed in order to fulfill the hosting of this product. What became more interesting later on, especially with all of our pre production capabilities, all the collaboration capabilities, is that there was a lot more value to the platform than just hosting. So if we collaborate on a Vercel project. We're just better at creating software. We're better at iterating. We're better at QAing. We're better at testing it out, getting feedback from others. In fact, I was just in a, in a morning session reviewing our upcoming homepage, which I'm really excited about.

And the team was using our product in order to exchange comments on this unit of work. So we, we complimented our initial price. And it was solely focused on infrastructure to, basically create a proxy for the value that the platform gives you as a whole, how much more efficient it makes you as a company.

So now it's a basically hybrid of what you would think of as the value that GitHub gives you and the value that Snowflake gives you on the infrastructure side. So Vercel provides you both ways of using the product. Uh, some of our customers use the entirety of it. Some of our customers use parts of it. We have, for example, customers in, in extremely highly regulated hosting environments that cannot even use cloud.

So they use Vercel as a way of speeding up the iteration cycle of their Next.js project. So they use it exclusively for reproduction. Let's call it more of like the GitHub use case. And then there's customers that say like, I literally have no clue how to provision infrastructure or interest in doing so.

I'm going to also host this global workload on Vercel.

Todd Jackson: And I'm curious to understand more how you think about product positioning, you know, sort of like the language market fit around a product. And maybe in the early days, it was sort of different. You know, the front end cloud is a very kind of like lofty product position. And I'm curious sort of how that's evolved for you. What was it like in the early days, and what is it like now?

Guillermo Rauch: Yeah, that's a very good question because in the early days, I think your priority should be to make yourself relatable to what already exists. If you have three landing pages, or you have a small team, you're kicking the tires on an early revision of the product to call yourself like some very lofty thing ends up playing against you because you're like, okay, well, what is that? Like, can you actually say in terms that I understand? Whereas for us, this idea of like providing front end as a service because of the maturity of the rest of the ecosystem, a lot of our partners, like when you use Shopify headlessly or use, uh, CMS' is like Contentful search engines like Algolia, even they are teaching their customers that their product makes the most sense in the context of a front end service existing.

And in fact, a lot of the tailwinds of our business have come from partners. We have partners that in order to demonstrate the value of their back end technology, their sales engineers, their, their folks that are guiding the prospect use Vercel to demonstrate how that power catalyzes in a real world product.

So now we sort of, I think, earned the right to try to define a category, try to give that lofty name to the category. But early days were like, okay, I remember at one point, I remember telling the team, this is a pivotal moment. I was like, folks, we need to change the hero of the landing page. It makes absolutely no sense.

Uh, and uh, Vercel has this capability where like every deployment you've made, you can go back in time. So the other day we're laughing because we went back in time. We're a little bit embarrassed because we had oversimplified the product. We're like, that's not where we were. Uh, but I had oversimplified it to the point of like my job right now it's just, I want to make it relatable. I want to catch the customer's attention. I want to meet them where they are. Uh, I can't remember exactly what it was, but imagine saying like faster websites made easier. Like it was a very simplistic thing, but it was relatable to where we were at the time.

Todd Jackson: Yeah, I'm a big fan of that. I think that early on you have to be very specific about what the product actually does and sort of like why it makes a difference. And then overall, you know, over time, like you said, you sort of earn the right to get loftier and higher level. It reminds me a little bit. I'm looking at stripe.com's homepage and stripe.com says financial infrastructure for the Internet. You know, but but 10 years ago, yeah, 10 years ago, it just was like a payments API that doesn't suck, you know, and you got to sort of start very, very specifically.

Guillermo Rauch: That's such a good example because the code snippet, when I first used it, it was like, Perl and an API call. And I was like, got it. Like, I'm, I'm there, Stripe. Like, I get what you're doing. Like, there would be no better way than the little code snippet to make me understand what it does. Uh, now you're more mature, that can play against you, uh, especially as the complexity of the product and ecosystem evolves.

A real world payment today, pretty hard compared to that. And, and by the way, that's a good example of also why folks are now making the introduction to their developer products a higher level representation, like a React component, because there has been a ton of complexity accumulating on the backend side.

It might actually be better for me to give you today the checkout component that is highly customizable, that is headless. Then giving you a bunch of API calls because you're going to be like, where do I start? Do I need to stand up a job queue? How do I handle my payment intent? Like no, like just here's the elements.

Here's the things that relate more to the product. That to me seems like the trajectory of the cloud, and that'll be how new products will be brought to market as well.

Todd Jackson: And so now over the years, you've established this high level category of the front end cloud or front end as a service after doing that. What has, what has the Vercel journey been like to a multi product offering? I think you've, you've done some acquisitions. You've also built a bunch of new stuff internally.

How, how do you think about sort of like going multi product and how to approach that?

Guillermo Rauch: I mentioned it briefly when you, when we discussed pricing. So, in the beginning, it was just managed infrastructure. That's our primary product on bring your Next.js workload, bring your React workload, bring your Gatsby, Nuxt, whatever, long tail of dozens of running frameworks. 

And then, we realized this incredible superpower of because our platform is so serverless and so fast, we create this DX platform, where the value is predicated on the iteration velocity. Maybe you have other infrastructure, as I mentioned, maybe you're on prem, but you want to move faster. So those are the two products today, Managed Infrastructure and DX Platform.

And now what we're seeing on the DX side internally, we've been calling it a transition from DX 1.0 to DX 2.0 is that AI is the next frontier for how we improve your developer experience, for how we make you more productive, for how we make companies iterate faster. So our latest product there within the context of the DX platform is V0, so you can access V0.dev. I think we're pioneering this concept of what we call generative UI. The idea is that you type in a text prompt in plain English. And we give you the real world React and Tailwind code that does exactly what you asked us for. And what we're infusing in this process is the sort of aesthetic sensibilities and taste and accessibility that makes a good product.

So we're literally trying to save you time from having to reinvent the wheel, either trying to create your own components or trying to assemble components that you find on the Internet. The, the catalyst for this is noticing that developers actually spend a lot of time copying and pasting. Even in 2023, like, there's abstractions for components, a lot of them are overengineered. The killer technology really is assembling things that you find on the internet. So AI is now making it possible for us to say like, hey, like, let us assemble the parts for you. And let us give you a very visual feedback. Because when folks work on the front end, they're actually assessing the quality by the visual representation.

Code in many ways is becoming less interesting, right? Cause it either looks good or it doesn't look good. It loads fast or it doesn't load fast. It's accessible or is not accessible. So so much of the front end cloud has been actually about the interaction, the speed, even the perception of speed. And so we want to create an AI product in the context of those requirements.

Todd Jackson: So let's, let's talk about AI cause I think it's a topic that's on everyone's mind. What direction do you see AI going sort of broadly in the next few years? And then what are the parts of that that really impact you and Vercel?

Guillermo Rauch: Yeah, I think AI will act as an accelerator of human potential. Too much is discussed in the context of it'll replace A, B and C, maybe for very narrow tasks that were primarily handled by a very specific job. We'll see, okay, so that job no longer exists. The vast majority of jobs that I am interested in, that my colleagues have, are very creative, right?

But sometimes the manual, tedious things, let's say like, some things that we do in programming are very manual, very tedious, very repetitive get in the way of creativity. V0 was called V0 because most projects, even in 2023, started with a blank canvas. I had this realization, uh, with Next.js, when you create a new Next.js project, we created this really fancy, nice looking splash page that says 'welcome to Next.js', link to the docs, link to instructions on how to deploy, link to, I can't remember, link to the credit of who created it, whatever. And how is that useful? You're trying to create the next website for the podcast.

How is that uh splash page helping you? And let's say that you actually say, well, I don't need a splash page, delete it. Okay. Now I'm on a blank page. So we need to do better in order to, for you to be creative. We have to give you the inspiration. I think this is what Midjourney did so well, where for one of our conferences in the past for next JSConf, we ended up using DALI for brainstorming what the artwork of Next.js conf is going to be. And it was an incredibly successful journey for us. A lot of those instances of AI is helping me be more creative or is removing all the tedious work that I do is really, I think, inspiring the next set of tools.

 I have some heuristics or frameworks for how I think about opportunities in product space, in the product space.

One is... anytime you're starting from blank, think about like, is there something I could have given the user?

I'm replying to an email or I'm addressing a support ticket, and I'm starting from blank. Has nothing ever been said on this subject? LLMs are pretty good at, you know, wordsmithing from the collective knowledge and memory of things that are related.

So I would say, you know, that's one opportunity. The other one is again, before that email, before that support case gets filed, could the user have helped themselves? Can we give them the co-pilot the assistance, the, uh, you know, personalization, the contextual documentation. And again, Vercel is a front end platform, makes creating these UIs really, really easy, so that the user doesn't have to get to that stressful moment.

The same goes for any time you're presenting an error. Any time you're presenting an error, can you actually suggest a solution to the error? Any time we're building UI today, we have to be asking ourselves, There's so much that comes with the inertia, experience is almost a, a, a crutch these days, right?

Because like we have this inertia when we build products, Oh, I'm going to design the error state. In an error state, the best that I can do is render the error. Maybe if you were a product person that was going above and beyond, you'd really care about the text. I remember an excellent article from Wix about how they sweated the details of every error message.

But you have to ask yourself, did I even need to give you a static error message or could I have given you more help? Um, Elon famously has this mantra of all user input is error. So you have to ask yourself. When I created that text box, when I created that, uh, input, when I created that link, was that necessary?

Can I simplify further? So that's why as a, obviously as a platform, we're biased because we're seeing so much excitement on building AI products. But even as a, as an entrepreneur, I get really giddy about all of these new products that will be brought to market. If you're willing to go further than the inertia of how that product was built in the past.

Now that you have this AI that you can integrate into the design.

Todd Jackson: And what are you seeing your customers building with AI? Have you think of, have you seen any cool examples of, of your customers using Versel to either build an AI product, or to use AI to build the product?

Guillermo Rauch: Yeah, we're actually in the process of beta testing a bunch of products built on our platform that are using AI to help us be more efficient as a company. So I kind of mentioned the one around auto drafting support responses. Uh, one that I'm really excited about that I just used for my own personal, like, education is thintool.com, uh, it's an expert in financial reporting. Like, I can ask it, what did Shopify say in Q3 about, enterprise e commerce, uh, or what acquisition did so and so make? Or can you summarize so and so? And what's really cool is that we're seeing systems that become experts in a specific domains. We're also doing a proof of concept for a legal AI product to help us accelerate the process of redlining and reply to customers and other things and just accelerate deal velocity.

So right now, there's, I think, four products that were in the process of procuring, the- uh, accelerate our own workflows with AI. The one where you get more information about finance is really interesting because the Achilles heel of a lot of AI chatbots today is jack of all trades, master of none.

You can't really trust the responses. They hallucinate. They're not up to date. They don't provide an experience beyond text, really. Like, sometimes you actually do want to see more, click around, other ways of interacting with the data. I do not believe that the only way we'll interact with data is just going to be like a chat UI with text.

That's a good way of showing the ultimate power, like the true differentiated skill of AI, but that's just one point interaction mode, and there's going to be a ton of others. So, we're seeing a ton of customers that are just bring in that capability to existing products as well. And they coexist with the more traditional ways of interfacing with their product.

Todd Jackson: Let me ask you kind of a far out question because, you know, you mentioned kind of the role of code changing, um, as we progress with AI. And I think it's interesting because as the technology becomes more advanced, it allows people who don't have traditional AI backgrounds to build products this way. How do you think the role of engineering kind of shifts maybe over the next 10 years or even 20 years with all what's happening in AI?

Guillermo Rauch: I think a lot of the focus shifts to creativity, really. The thing that we've been trying to do with the front end cloud, it accelerates. Which is, work on your product. Work on the user interface. Work on the thing that touches another human being. And gives them a great experience. So I think there's going to be a very dramatic acceleration there, because the last thing we all hypothesized, the last job that was going to be quote unquote threatened by AI was programming.

Lo and behold, AIs are excellent at programming. Which means that we can start moving into the next step, which is that what is the product supposed to do? What is the experience supposed to be? What does it look like? I think it becomes a lot more about the exploratory approach to building. I call it the minority report.

They're like, I'm going to explore in space what all the possibilities are. The curation of those suggestions. The feedback that you give to the system, the things that you learn from your customer, a lot of experience are going to become more spontaneous, right? The thing that we want to accomplish with the web is that we, we want to make it truly an AI driven web where when you go to a website, you get a copy of that page that is just for you generated just in time.

And it knows, it has all this context about what you want to accomplish. This has been the dream of the web for as long as we can remember. But as I mentioned, we had all these roadblocks along the way, right? Like the static problems, the caching, the outages. The other profound change I think will be in that when customers hear this, they think it's freaking science fiction, cool, this, this guy in San Francisco is just like trying to like predict the future, whatever. But we will have systems that help you migrate from where you are today to this world. It's not just that we present to you like here's the next generation flying car, hop on it and leave behind everything you've built for the past 100 years.

It's the opportunity to meet the customer where they are and use AI to incrementally adopt and migrate code as well. That I'm really excited about it because frankly, the major thing that I've learned about, as we bring Vercel to more, mature and, uh, upmarket customers is they've earned their legacy.

Some of them had the first dot coms that ever existed. I met a fashion brand recently that was, their team was so proud if you ask their founders or their, their, the heirs of this company, they were so proud that they were an early adopter of the internet. And of course, now that became the legacy.

They, they, they were early movers, but what about the subsequent three revolutions of the internet? Not so fast. So using AI to continuously modernize. You can think of systems of the future that are self tuning and adaptive, we no longer have to catch the latest trend or optimization by doing major replatforms.

So that's kind of the, the world that we're headed towards more creativity, more automation in how we get to that creative base.

Todd Jackson: Do you think that in 10 to 20 years, engineers will still be writing code by hand? Or do you think that kind of goes away?

Guillermo Rauch: If I had to bet, since you gave me the 20 year out, I would say, yes, I think very little code, if any, will be written by engineers. I think, do I see a world where we hit, um, a limit on the overall large scale reasoning ability of the model where like there is a ton of context \ in very large, a very large state space of, of, you know, how all the systems connect with one another, so we switch into a different kind of programming. I could see that happening as well, but there's no world in which we're not working side by side with the AI on these systems and where the AIs are the ones that are doing the heavy lifting, the ones that are suggesting the next move to us. And I think we're still in control.

And if we're not, I think we have bigger problems like the, all the AI safety conversations lead us to believe. I still see the human being as a driver, but we continue to abstract out this software 1.0 stack more and more and more until you don't even know it's there. I think it's not out of the question to believe this because if you look at how you don't think in terms of the processor instructions that the compilers generate anymore, you have absolutely no idea. Most systems you don't know what the uh, JIT, the just in time compiler optimizations that are being performed are. And you don't know what the behavior of the garbage collector is, until you have some kind of very specific problem of optimization that you have to do. So, that's kind of how I would imagine the AI code to behave.

More as the output of some higher level representation rather than what we see today with the code we write.

Guillermo 

Todd Jackson: this has been awesome. I wanted to ask you one or two closing questions just here. If we have a minute. Um, what is some advice that you find yourself giving out over and over again to other people?

Guillermo Rauch: One of the frameworks that is more abstract that I keep coming back to is I advise folks to focus on iteration velocity. Rather than speed, so velocity is speed with a direction you're, you're, you know where you're headed, or even if you don't know where you're headed you have the awareness that you're, that you're seeking a direction. And seeking direction doesn't mean you're just like writing code 20 hours a day and just churning out features left and right.

That may not really take you to where you need to go. It might be that you have to sit back and talk to a prospect. To really discover their pain, to rethink your approach. Maybe you've just gone too far down the wrong direction and you don't, of course, correct by moving faster in other- it seems obvious, right?

Like, if you're off, you're not going to get faster to where you need to go by just, you know, moving in place basically. So the ways that this has shown up in my career is that sometimes the solution was to build less, and focus more. Sometimes it was to really pay attention to what customers were trying to tell us. Right? Like sometimes folks are maybe too nice when they give you feedback or too succinct. So you have to actually put in the work to discover what's behind that feedback. What's behind that metric that is not going to where you would like it to go. So I think overall velocity, and for someone that is just so obsessed with speed, because I love fast more than anything else.

I think that was the right complement that I needed to add to my framework to be truly successful in a durable fashion. And I think in the early days, finding that direction is the most important thing you could be doing.

Todd Jackson: Is there any other advice if you could go back 10 years and talk to, you know, younger version of Guillermo, is there any other advice you'd give yourself?

Guillermo Rauch: Yeah, I think at the end of the day, it comes down to like saying no to more things. When I launched Next, concurrently, we launched another two really successful open source projects. And there was just no need. I could just, Next is, look at it, we're like, seven years later, I'm still working on uh, making it better, faster, stronger, scaling into larger code bases.

So I think picking battles and, and really going deep and, and just really learning to say no. I go back to the Steve Jobs wisdom of: it has to hurt. Cause like the things that we're, we say no to these days are awesome ideas, truly, genuinely interesting, potentially beautiful products. That every day we work on the courage to say, nope, more depth to that other thing.

And it's a continuous thing. It's not, not a one time, oh, I, I should have done that 80 years ago. It's a continuous thing that you work on. Same thing with investing that time in the discovery and the true understanding of, of customer pain. And, and, and, and being very, very, very honest with where, with whether you meet the bar. And being honest to your team, of course, being respectful and conveying feedback really well, but being honest with where you're at with that quality that you're chasing with the iteration velocity that you're chasing.

And frankly, we're here to raise the bar. We're here to cause, especially leaders, we're here to raise the bar. And that's for ourselves in the way we communicate, in the way we build, the feedback that we give, the feedback that we seek. But just continuously raise the bar.

Todd Jackson: Guillermo, thank you. This has been terrific. We covered so much ground today, and you've been so successful and so willing to share kind of what you've learned along the way. And I really appreciate it. I know founders out there do too. So thank you.