The Vercel Journey 🔺 — with Guillermo Rauch

And I know that you recently hosted a great episode on complexity. So one of the key challenges that companies like Vercel have, and I'm all for it because it's sort of been the calling of my life, is what I call the progressive disclosure of complexity. So I'm building a platform that should not be intimidating for your first line of code and gives you the superpower that you could be one day a top 30 internet website. With the same infrastructure, with the same tools, with the same access. You know, when you learn this technology, it should be a technology that lasts you a lifetime. It should be a skill that gets you, if you want to, in a really good place in the global job market. Or it should be a technology that's also fun.

Hey, Luca here. Welcome to a new episode of the Refactoring Podcast, where every 2 weeks we interview a world-class tech leader and we talk about the future of software engineering. Today's guest is Guillermo Rauch, who is CEO and founder of Vercel and who needs truly no introduction. With Guillermo, we talked about his journey in tech from a small town in Argentina to successful open source developer to CEO of a billion dollar company. Then we covered the unique Vercel model, which combines open source and commercial work. And finally, we discussed the future of AI, engineers, open source and software engineering at large. So let's dive right into it. Hi, Guillermo. Welcome and thank you so much for being on the show today.

Thank you, Luca. Super excited to be here.

So Guillermo, you are the CEO and founder of Vercel, which needs very little introduction to anyone working in tech. But I find it hard to define as a company because you do so many things. You provide hosting, but you also work on web frameworks. And more recently, you created also v0, which is one of the most popular AI coding tools out there. So what's your elevator pitch for what Vercel is and what it does?

Yeah, at a very high level, we simply create the tools and infrastructure to create and ship the best experiences possible on the web. So like you said, we host websites, we host web applications. But one of the things that I always sort of project into the world is I want to be able to go to a website and it's so fast, so innovative, so dynamic, so personalized that I must then think it's hosted on Vercel. So our goal in this world is not to just create average experiences, is to create the highest quality possible experiences. Yes. And we believe that in order to do that, you have to create amazing tools. Yes. So a lot of cloud companies like AWS and Azure have created amazing low-level infrastructure, but then it's up to the company or the individual to assemble the frameworks, the tools, the compilers, the bundlers, all this very advanced technology, right? To then create an application. And I thought when I started this company, I'm gonna take on more of the problem. Yeah. I'm gonna create an end-to-end platform, the complete platform for the web. And that concretely became Next.js, which is a super popular open source web framework based in React and the cloud infrastructure piece, which is in order to make a great application worldwide that is fast in Italy and is fast in the United States and is fast in Argentina, we have to deploy globally, which is also very, very difficult to do. So to manage global infrastructure, the caches, the invalidation, the propagation, It's always one of the hardest problems in computer science. So, you know, let us take the burden of distributing the bits worldwide and you bring your ideas and creativity. And in that context also, we created v0, which is an artificial intelligence tool. The idea being you just prompt in English or Italian or Spanish and you say, you know, create an application that tracks the time that I spend on meetings, for example. Yes. And so you type that in and Vercel uses all of its institutional knowledge and experience and context and prompts to bring that idea to reality.

Yeah. Love that. Love the definition and love the angle that you started with. That is, you go to a website and we can, I think we, as developers, we can always remember situations where we loaded the website and it was maybe so fast, so reactive, and we had to ask ourselves—

They're like, what's behind this? Right?

Yes.

I love that.

Yes, exactly.

I mean, you know, a lot of people ask me what's the secret sauce for creating, you know, such successful open source projects and whatever. And I'll tell you, I'm glad that you're pointing that out because I've never been too attached to any technology, contrary to how it might come across on X, because I love, you know, I love our technology. So I talk a lot about them, but I'm attached in a way that it's because I validated it with the experiment that you just mentioned. I only get attached to a technology if I put myself on the shoes of a user. Yes. My mom. And she opens her favorite news website. She opens an AI chatbot that she just got invited into, whatever it is. And if it's delightful, okay, my next question is, what is the technology backing that? And I think we sometimes forget how much developers do that exercise. Yes. Because we've all been trained to constantly measure things and we have very good pattern matching. It's like, I used to play Counter-Strike and you start developing the sensitivity for latency so that you can frag your enemies, right? So you notice the difference between 10 milliseconds and 100 milliseconds and a second. Yes. And I think developers are sniping the web constantly and over the long periods of time, they favor the technologies that deliver the best products.

Yeah, I love this definition because it's exactly true. It's like second nature sometimes, you know, just— Opening up the developer console when you're in a good website, it's just like a reflex, just like sniping someone on Counter-Strike.

Yeah, that's a good one.

I think it's a good one. Yes. So I like to start many of these interviews by talking about our guest's journey in tech. And I find yours particularly fascinating because first of all, you don't come from one of the big tech hubs, to say the least. And also, as it showed already in these first seconds, you are a developer first and foremost, and then gradually transitioned into this, actually, the CEO of a billion-dollar company. So how was this journey in tech for you? What are your favorite highlights?

Yeah, obviously it's very surreal to have had the privilege to be where I am and have grown the company and have gotten all the resources and help from the people that have made this possible. And I would have never imagined that things would get so big. And at the same time, it has been the calling of my life to work on this technology. Like you said, I started out as a web engineer. So I tried out a lot of technologies when I was young to learn to program. And the one that really captured me and made me fall in love with programming and doing it a lot was the web. If it wasn't open source and it wasn't web-based, If it wasn't for those two pillars, I would not be where I am. I tried everything else. I tried C, C++, Java, Visual Basic, Delphi, Pascal, everything. There's a longevity and there is a dopamine hit to being able to create something and share it as a URL. And so I was born in a pretty humble area in the outskirts of city the of Buenos Aires called Lanús. To, to your point, not a tech hub, to say the least. Maybe a soccer hub. So Maradona is from this neighborhood. And so totally a soccer hub and a place with where big dreams are born. But if you think about what made it possible and will make it possible for a lot of people in the future, for anybody in those situations, to be able to get in touch with the world. I believe that my sort of shortcut or secret code was pushing things into URLs, posting them online, getting other people to share them. I remember early on I wrote an open source project that created a really slick animation for a menu.

Yeah.

So it was called Fancy Menu, actually. And it got posted on a blog that was really popular at the time called ajaxian.com by one of the engineers that ended up working at a lot of web projects at Google. And I was 16 years old at the time. In fact, in the blog post, he said a 16-year-old hacker created this and whatever. I was still like in Argentina. And I encourage people now to like follow that journey of like come up with an idea, V0 it or, you know, sit down and code it, deploy it into a URL. Obviously, if you use Vercel, I'll be happy, but use anything that can put it into the open internet. Yes. And you're, you know, you're now, maybe this is a bit of an exaggeration, but you're kind of on even ground with everybody, with the most privileged first world countries, the most powerful economies and whatever. Your ideas are now head to head. So going, you know, massively fast forwarding to Vercel, it's the same idea that everybody can cook, everybody can bring their ideas to life instantaneously, everybody can share them. Now, how do we become a billion-dollar company? Well, it's because we support companies of all sizes, right? Like it can be people that have their first idea or just learning to code. But it's also the largest companies in the world. In fact, I was just tweeting before this podcast, I just heard from a teammate that we are onboarding the second website on Vercel that is in the top 30 highest traffic websites on the whole internet. So, we already have one and this would be a second in that cohort. And so, you have to be able to straddle and sort of cater to the needs of incredibly sophisticated customers and also the people that are just learning to code. And I know that you recently hosted a great episode on complexity. So one of the key challenges that companies like Vercel have, and I'm all for it because it's sort of been the calling of my life, is what I call the progressive disclosure of complexity. So I'm building a platform that should not be intimidating for your first line of code, and gives you the superpower that you could be one day a top 30 internet website with the same infrastructure, with the same tools, with the same access. You know, when you learn this technology, it should be a technology that lasts you a lifetime. It should be a skill that gets you in a, if you want to, in a really good place in the global job market, or it should be a technology that's also fun. Like I code during the weekends, you know, like I, to your point, like I started out as an engineer. I'm not the CEO of the company, but I wanna have fun and the web is a fun medium. So that's kind of the spread of Vercel.

Yeah. I mean, I love this answer so much to unpack here. I would have like 100 follow-up questions. So for example, one angle that's so interesting to me is how you're able with the same product and the same infrastructure to serve both solo engineers who are just coding their toy project for fun in the weekends and a top 30 website on the internet. How can you do that? What are the qualities that you had to create, to exhibit, to be able to work for both of these parties?

Great question.

They have nothing in common.

Yeah. Number one, my inspiration has been the products the technology products in history that have successfully straddled that. Hmm. This is not directly one-on-one to developer products, but I always think about the iPhone.

Yeah.

I have young kids and I've now run 5 A/B tests, so to speak, of how quickly do they learn the touch interface of the iPhone or the iPad. It's almost like a miracle technology. My 1-year-old, my youngest already uses the iPhone and iPad. Yes. I also have the, uh, very personal experience of my grandma in Argentina until she died was communicating with me daily on iPad and Messenger. So a 90-year-old and a 1-year-old, but also all the business users on the planet, right? Like all the enterprise. I work I do so much of my work on this thing. Yes. Through apps like Slack and Gmail and V0, which is coming soon to iPhone. And so that's kind of the inspiration. I know that it's possible for technology to have that progressive disclosure of sophistication. And so one of the elements there is that it has to start out very simple with very few inputs. The reason that my baby learns iPhone is that he touches a little bit and it's safe, it's fun, it's reactive, it's instantaneous. There's not a ton of skills to learn like typing and mouse pointers in order to get into it. So the barrier to entry has to be very, very low. So in terms of practical examples, one of the things that I was obsessed with open source API design and using now LLM lingo because I'm so LLM pilled, I call it token minimization. The very first page of Next.js takes, I believe when we first released the framework, it took 4 lines of code. So here's the ingredients. You open a new folder, you npm install next, you create a pages folder inside of it, and you put an index.js file inside of it. And you say the 4 lines of code are, and one we removed actually, it was importing React, I'm gonna get a little technical here, but you had to import React because JSX, the special HTML-like syntax, required implicit React.createElement calls. No longer necessary. So now it's 3 lines of code, or maybe even 1 line of code. Export default, and you can do an inline function, so it's 1 line of code. Heading 1, or marquee, or header, or paragraph, whatever. Hello world. So you had to create a folder, put in a file in there and one line of code and aha. Yes. Now you have your first page on the internet, let's call it, but you're working on the same technology that scales in order to power those top 30 websites in order to power walmart.com. How do we do that? Well, as you continue your journey of learning what you can do with this technology, we disclose and we add more complexity over time. So, and that complexity should match your requirements. So maybe you have something that is very simple and client-side and doesn't require a database. So you start adding some React hooks. Maybe you need to do some data fetching from the database. And this is why I'm excited about our newest technology with React Server Components. I always think of it in terms of like, well, it should be two lines, two extra lines, one for importing your database. And another line for getting the data. And actually the inspiration there was PHP, because when I got started programming, I think people in the audience might be thinking, well, is this guy just describing PHP? And I'll get into why it's actually different. But it was kind of like an aha moment that you could throw a file into your Apache web root and Voilà, the internet. You've merged with a machine, right? And so in terms of that disclosure of complexity, one of my inspirations when I was a kid was applications like Gmail. Hmm. Applications like Gmail have tremendous amount of client complexity. Yes. They have all these sorts in real-time capabilities. Yeah. And I remember one of the things that I loved in the beginning that people were losing their minds and it's so commonplace today is like, so easy to select and drag and drop from the checkbox. Yes. Boom. To select a bunch of emails and archive them and whatever. Or the experience of setting up a filter. Boom. Create filter from this. Pop-up comes in. Gmail makes a search of your inbox, shows you a preview of what you're going to filter. It was like seeing God. Yeah. All of that was pretty—

Can I stop you here for a moment? I have this very similar memory about this. I think that at least for me then, of course, I was not very well educated about the whole landscape at that time, but I think Gmail really felt the first large-scale web application that felt—

It was mind-blowing.

Desktop class. And so like client-heavy that kind of redefined what you believed it could be possible in the browser in terms of complexity. So yeah, I have this kind of very similar memory.

And that's why it couldn't just be PHP and it had to move on, right? Yeah. Because in order for that Hello World to scale to something like Gmail or ChatGPT or Groq.com, which is built with Next.js, I knew that I needed, basically needed JavaScript. JavaScript and TypeScript are amazing because they can run on the client and they can run on the server. So in many ways, sometimes I thought a little bit like a betting man. And I've thought about this, like, what asymmetry can I find in the market? Like, it kind of like when you're, you're like, you cleverly pick a stock, right? Yeah. And the stock that I picked was JavaScript because it had this incredible privilege of it can run in the client. It was like, oh, no one else can. You know, some of the best companies, sadly, some of the best companies in the world sometimes have unfair advantages like this. Network effects is something that's like very hard to crack. For example, a really good example of an amazing business is LinkedIn, and they have an amazing position. Like, it's so hard to displace them because they've created the network and they create— they have a lot of value for people, but like, there's— there aren't a lot of alternatives, right?

Yes.

And so JavaScript has earned, I argue that it's earned. Some people, you know, say it's still that it's not a good language, whatever, but like it competed with Flash, it competed with Java applets, it competed with a lot of experiments. It competed, in fact, we're talking about Gmail, it competed with something called ActiveX on Internet Explorer that allowed you to do those AJAX calls and it won, right? And once it won, it now has the quote unquote network effects of 8 billion devices, whatever, like every person on the planet is carrying a JavaScript running computer or virtual machine. And so the idea behind Next and Vercel to a great extent was, could we bet on that? Could we bet on the fact that this little language that started out to just bring a little bit of animation into an element could grow to be that application platform that you just talked about, the fact that Gmail was a desktop-grade application in the web browser is the actual dream of Vercel. Meaning I'm not here to just create like static pages on the internet. You know what I mean? Like I want the web to actually be the winning and dominant application platform of the future, better than any mobile application that's in the App Store ecosystem could be, for example.

Yeah, yeah. And it looks like a successful bet, the one you made.

Yeah, I think it's turned out really well. TypeScript brought JavaScript from a fast prototyping language into an enterprise-grade language. In fact, the type system of TypeScript is the envy of a lot of programming communities. Like, it's not just like, oh, we got something okay. We got something exceptional. Kudos to the TypeScript team. We got a lot of IDE tooling. We got a lot of, I mean, now with LLMs, we have a lot of training data. Like LLMs are good at, fundamentally, they're good at JavaScript, I would argue. And they're good at Python as well. But like the killer app of AI in many ways is React. So the bet really panned out in a number of ways. But I think ultimately it's been about betting on the web and betting on that the web could do more. Yeah. And I think you can still do a lot more. And that's what we're investing.

So I think part of this bet reflects in the way you're able to marry, combine open source and commercial work, which is one of the things that I think set Vercel aside from many other companies. And it's one of the few examples of commercial companies finding real success in this. So not just your hosting, for example, but the stewardship of Next and contribution to other projects. So one question that I wanted to ask is, of course, working on these different levels of the stack brings all kinds of synergies, but it can also draw controversy sometimes because you have to like marry the expectations on one side of people that they are using the open source software and then you have your own needs as a commercial entity. You need to make the playground fair, the incentives aligned. So how do you navigate this conflict? If you feel that there is a conflict at all.

I don't think there's a conflict because fundamentally open source at this really high levels of execution and sophistication is a very demanding, it's very demanding work, right? So I'll give you an example of a project that we fund is we are rewriting a lot of the JavaScript native tooling. In Rust. And the reason for that is that as the web has moved from being a static to a dynamic application platform to now powering a lot of the AI experiences on the internet, the number of files, modules, size of the applications has grown tremendously. And it's not enough to just have JavaScript processing these files. It's too slow. And so we had to fund a massive and hugely ambitious compiler project that takes like a dozen compiler engineers. Why are we motivated to do this? We're motivated to do this because the more people that use Next.js, some slice of that pie will use Vercel. And where I think the false dichotomy emerges is that the best thing that could happen for Next.js is for the pie to get so large that were just really happy to have a slice. And rather than me saying, you know what, like I have 1.3 million developers, how can I get those 1.3 million developers using Vercel? That's not how we think because we think of 1.3 million developers as being a tiny number actually. Obviously, like it's a huge accomplishment, right? And I'm extremely proud of it. But if you look at like the web and the internet is such a massive place, Think about how many WordPress sites are there. Think about how many legacy CDN solutions and legacy security vendors and whatever, like the web is gigantic and still growing, especially in the world of AI. And so we want to create a synergy that makes a whole ecosystem invested into this project and also create a funding mechanism for the project. So when I started Next.js, funny enough, I had no business idea behind it. I, some people think I'm some kind of genius that thought about like Next and the deployment story and whatever. We had an internal problem at Vercel, which is I wanted to create the first website for the startup. And it was a simple website. It had a form. It had a couple of pages. It was gonna get, it was then gonna get our dashboard, our documentation. And to get started with React doing that was an absolute nightmare. And I kind of got sidetracked. In fact, I've had a lot of like side quests as I built this company because I love open source. So I don't know, maybe you might not know this. I created a terminal emulator called Hyper, a standalone terminal app as a cool open source project of the Vercel family. And so The way that I've always worked is I have a problem. I think the problem is shared by a huge number of people. I think the problem is so important that a lot more people are going to have it in the future. They don't know it yet. And the way that I tend to want to solve those problems is through open source. And that's great. The problem is that as a company gets bigger, how do you make sure that you have a sustainable funding mechanism? For those open source projects. They take a lot of time, they take a lot of resources, they take dedication. They take a security team, for example. When people report CVEs, we're working around the clock. We have a 24/7 on-call just for the open source project. And so finding that synergy has really been the key unlock of Vercel and the thing that I'm proud of even more so than the size of the business.

Yeah. So you're saying the North Star needs to be the maximum adoption and quality of the open source project as opposed to, I don't know, maximizing the— Yes. Well, I'm guarding against things like developing stuff for Vercel that creates higher lock-in and devalues the open source.

That's why open core never made sense to me because open core is saying, well, I'm giving you a lesser version of the product. Why would anyone adopt something that they know is a lesser version of the product? Right? And one of the things that we've done over the last couple of years is even work with industry partners.

Yeah.

On making sure that they have access to the APIs that would allow them to create competing services to Vercel, which is an infrastructure kind of project, right? It's more of a CDN. It's a security layer. Of course, it's a hosting layer, but it's also a build pipeline. There's a lot of pieces that if you, if you zoom out, Vercel is actually more like AWS than Next.js. Next.js is one of the multiple frameworks that we support. And the important thing is finding the right adapter between these two things so that other people can also create their own solutions that are alternatives to Vercel. And that can be sometimes, you know, almost like a paradox because you have to wear two hats. But I think it's worth making that effort because that pie getting bigger is so much more rewarding than, again, like you maximizing the capture of whatever size of the market you have at any given time.

Yeah, I agree. Yet I think there is so much open source out there that works instead the way you said before. So you either adopt something that is free, but a lesser version of the commercial version, or you use something that instead is paid for. So do you have any advice for engineers trying to make a living out of open source projects or creating like companies that have good synergies with these kinds of projects? And many engineers are still struggling because it's well known that it's a hard thing to do.

Yeah, there's a couple of things that have emerged. I think the obvious one is that managed infrastructure versus DIY, it tends to be a really good balance. Like you look at projects like Supabase or what the folks at Terso are doing, and they open source an enormous amount of code and value, but they also create a value for people that say, you know what, I don't want to manage this. Yeah. So in many ways, the Vercel platform is the managed infrastructure for hosting CDN, WAF, firewall, et cetera, that you could assemble all those pieces together. The other thing that I think we've done quite well is Next.js is an application framework, but in order to actually productionize an application that is really fast and secure, you need globally distributed infrastructure. So we built an edge network, we built our own CDN, et cetera, And those are the kinds of things that people tend to not desire in open source. Like you orchestrating 20+ Kubernetes clusters worldwide, terminating traffic, applying DDoS mitigations, all of the things that we do day to day to protect you and run your application as fast as possible, I think are natural complements. So if you can find natural complements, that people will not even expect to find in the open source repo. Maybe there's other repos that one could create, right? Like you could create another sort of open source, there's open source alternatives to Vercel too, right? There is projects that say, okay, can I assemble all the different components in clouds like AWS in order to create a managed deployment platform? Also totally fine, but it's almost like a different kind of project, right? So if you find those natural complements, I think that works really well. The other thing that I've been really excited about is AI. So we kind of see this with like the VS Codes and Cursors of the world of like, look, this editor, there is an editor here, especially in the case of VS Code, it's open source. But if you want the AI superpowers, you pay us. Yeah. I find that to be a pretty cool synergy because I am very bullish on local models over the long term and open source models, very bullish as well. But right now, the desire, the customer demand is for as much intelligence as possible. Yes. And this tend to be beefy pieces of infrastructure that run in the cloud. And so that to me feels like a very nice synergy as well of like, Here's a tool. It's open, creates enormous amount of value. Let's build an ecosystem around it, an open platform. People can create plugins, et cetera. But here's our solution for like how to like make this thing more intelligent. So I think people are very happy to pay for intelligence that saves them time. And that's also an area where if you zoom out, v0 exists. To almost be the next generation of frameworks, I call it. A framework was me and my peers thinking really hard about how to make the job of another fellow human really easy. And so we put all of our experience in the form of guardrails and abstractions and errors. But the next frontier is not that the framework gets suddenly 100 times smarter, that someone comes up with this secret API that is just gonna take the job from being this easy to like this easy, et cetera. I think it's gonna be AI. AI, I call it developer experience 2.0. And my colleague who's our VP of AI, Jared Palmer, says it's very likely that React and Vue and Svelte are the last frameworks.

Yeah, I wanted to ask you this. Go on.

And then I have a— Yeah. And it's a hot take. Like he just like sent tweet, you know? But think through it, right? Like, is there a— do you think there's going to be lots of engineers that are going to come together like and say like, you know what, let's reshuffle the entire ecosystem away from React into something new. Even if that ends up happening, it's going to be because AI decides that the tool is better for its outputs rather than like a first principles new framework. So I agree with him. React is almost like the last framework of its kind. Yeah.

Yeah. It's very interesting because you mentioned the case of you and your friends sitting down to think about frameworks and improving the developer experience. But what does it happen when these frameworks are largely used by AI and not people anymore? I mean, they either improve them by themselves or the incentives to do this, that is very hard work, is way less than it was before. But maybe it's not that outrageous because, I mean, once the platform, meaning as the web gets consolidated, maybe it's fair fair that there is at some point some consolidated frameworks and we don't need to reinvent the wheel from scratch.

Totally.

As we have done, as we've done, unfortunately, maybe, I don't know, many times.

Many, many times, right? Like the meme when I started Vercel, I remember walking into a venture capitalist's office and I told them that I had this idea and like Next.js is doing really well and whatever. And they're like, I don't know if this has lasting power because developers change their frameworks every day. And by the way, that was kind of a, not a terrible take at the time, to be honest. I was so bullish on this ecosystem. And I told you from the first principle bet of React was the only framework that I had seen that could model client and server really well. I almost became obsessed with this problem of, I wrote a book even on this called Universal JavaScript. Isomorphic JavaScript, something that could run on the server and then be resumed on the client. And React is one of the few technologies in the world that could model that resumption and share code between the two sides of the, the two computers, as Dan Abramov calls it. And so because I had that first principles bet, I was able to like not get too discouraged by by the diss of like, eh, your framework is going to change. It's going to be replaced by something else next week. But I agree that in the future, LLMs might decide different things, like maybe drop down a level of abstraction, maybe even higher level abstractions, to be honest. We're finding that, and I think this is common knowledge by now, but AIs tend to be really good on like a surgical basis, at least for now. And we can't make a lot of predictions about AI because I don't think anybody could have predicted even Word2Day or ChatGPT or all of these things, right? Not even the experts. But you throw it the entire code base of OpenSSL and you tell the AI, make it faster. I don't think the AI would even know where to start. I don't know that it could keep in mind, so to speak, all of the requirements of integration of OpenSSL in the millions of codebases that exist. Yeah. And actually drive an end-to-end performance improvement across all of the platforms that it compiles into that is secure, et cetera, et cetera, et cetera. It could help you. It could be a reasoning partner. But we're not at that point yet where like it can operate at massive scale of codebases.

But do you think this limitation, the bottleneck is the intelligence itself or is it how we pass context? I mean, maybe RAG systems just need to get better or context windows larger or just we need smarter models. So it's a matter of—

All of the above.

You have an opinion.

I think it's all of the above. I think the context problem is real and the performance problem that comes with the context size is even a problem as well, right? Like if you give a lot of context to the model, sometimes it loses its train of thought, so to speak. It gets much slower. So the iteration times decay. Selecting what pieces of the codebase to actually give to the LLM is a task that today is still still tricky and we use heuristics, we use search, we use codebase indexing. They're imperfect techniques. I think as models continue to get better, the size of problem that they can tackle gets better. It's something that we've seen firsthand with v0. When v0 launched, it could realistically only work on small components.

Yeah.

Then it could work on entire pages. Then it can work into multi-file, multi-page, multi-component systems. Now it can do full-stack applications. So we have seen that. However, you get to a certain point where the LLM is still like hits a limit, right? In order to overcome that, we will do a combination of traditional software engineering techniques that make the existing generation of LLMs smarter. In divide and conquer, but we will also invest in smarter frameworks for the LM to work with. And that's why I was saying that Next.js and React are almost like the last frameworks of their kind because the requirements of the future will steer us in the direction of frameworks that are good for the agent. Yeah. Frameworks that are good for the AI interface and not just for the people.

What do you think makes a framework good for the AI in a way that is different from good for the human?

Yeah, so there's a bit—

certainly to say, I don't know.

It's still somewhat early to say for sure. One of the things obviously is there has to be huge amounts of documentation and demonstration data on how to use this framework correctly, right? And that's why Next.js has had an advantage here because think about how many Stack Overflow ques— I think before Stack Overflow started kind of in some ways getting replaced by the AI engines, I think maybe even the last year before ChatGPT, we were the largest, I don't know if it was the fastest growing or the largest overall tag of questions was Next.js. And so having, and this is again where open source is so beneficial for the world, right? There's so much data, so many GitHub issues, so many Stack Overflow questions and answers about Next.js and React. I think there's been a natural momentum. There's also the, what I call sort of like local reasoning capability. So because it's very hard for the AI to like think through 20 different files and connect dots and whatever, if you can create, and this is why I like technologies like React components and Tailwind and so things that you can cook on locally. In fact, one of the things that I loved about React that in the beginning wasn't true about React and I, in so many ways I wanted Next.js to help fill that gap was I wanted to be able to work on a component in system A and I can grab that component alone and throw it into system B and it looks perfect and it works perfect. That was literally impossible to do with jQuery and all the technologies that, uh, predated it. There was so many global side effects. I think it was Pete Hunt in the React team that called global side effects are the root of all evil. Global state is the root of all evil. jQuery had an assumption about the cascade of CSS selectors, for example. CSS selectors that are named by humans have global side effects, right? You go over here and you say, oh, I'm gonna make an innocent change to .button. And you literally just broke the business because .button was used by the PayPal checkout. And some engineer working on the settings page destroyed the checkout that is responsible for 70% of a public company revenue. So PayPal moved to Next.js App Router. I'm really proud of that. And I can tell you they moved to it for reason A, B, or C or whatever. But I can tell you that it's impossible to work at scale between humans when you have this global interference. And so I strongly suspect that what was kind of a nice to have so that teams could work better in the previous world will be an absolute table stakes capability for the frameworks that are going to work best with AI. Because again, AI will be best in the current generation technology caveat, whatever. When you can work on a slice of the problem. Yes. And that problem fits like a Lego brick to the greater system and to other systems. That's why one of my famous quotes on X when, when in the early days of React was React is like Lego bricks for adults. It's, I stole it from Paul Graham who said Lisp is the Lego bricks for adults. I don't think Lisp I mean, I know that he loves it, but like, and I can see it from the S-expression beauty of it that he composes so well.

He was optimistic a little bit.

But yeah, like, Lisp is not even that popular. Lego is really freaking popular, right? So, um, but I love the analogy.

I love the analogy. I think one way to see that, that I always think about is that the original way that the web worked where you had this separated style sheets, markup, and JavaScript, it's like versus the way components work today, it's like the difference between organizing a company by function entirely or by creating small cross-functional teams. You know, you have a team that can do everything, is isolated versus you have everything global with these global functions. And that's probably a problem at scale. Scale, not because of performance or non-functional stuff, but just for the organizational side of things, if you had to work together with people on these things.

And interestingly enough, I conceived Next.js as going back to like how you could go from like a developer writes a line of code to top 30 website. One of the key obsessions that I had in the very first document that I ever wrote about Next.js was that idea of like, how can it scale to multiple people working on the same codebase? And so there was a small engineering detail, which was when you, one of the challenges with JavaScript that didn't exist in PHP is that in PHP, you could have index.php, settings.php, about.php, you could have all your routes. And those systems could get arbitrarily large without disrupting the other systems with some caveats. Like if common dependencies become very large, startup times, especially in older versions of the PHP interpreter that I was used to, the cold start times of a path would become pretty significant. And then you would have to turn on the opcache. And whatnot. And then I think PHP today has a JIT. So either way, like it's very important to me that if I get big, if I get fat, I don't have negative side effects on my teammates. It's my life, my choices, my area of ownership. And so the implementation detail that went into Next.js is each route defined a code splitting entry point. So code splitting is a foundational technique so that bundle size doesn't inflate monolithically. And this is a key property of the web. I'm gonna take that further. When you get a new phone and you download the Facebook app, you are downloading these days, I think it's like 500 megabytes of code. Yes. Apple has been giving people more and more and more quote unquote bundle size and package size over time. It's truly a horrifying experience when apps get updated and you can't open them because these apps grow to be like mini operating systems. The web has an advantage here, which is that I can send you a link to groq.com. You've never opened it before. In my deadline that we can make possible with technologies like Next.js and Vercel, I can have content in front of your eyes anywhere in the world in 100 milliseconds. And that includes TLS handshake, TCP, DNS, processing and routing of the request, and flushing content and data from the CDN edge. 100 milliseconds versus 10-minute downloads. That's one of the elements of how we win in the war.

It's insane how many things we take for granted, I think, about the web and the benefits and the upsides versus other platforms. Yes. And, but when you look at it, it's really incredible.

And so one of the things that makes it possible to give you stuff in 100 milliseconds is that we do that server-side rendering optimization, right? Like, even if you don't server render everything, I already have something in the global network that can start streaming content. It's almost like Netflix. Like, here is like the first scene of the movie that you're about to watch. But then there's a lot of applications that need to run code on the client. When they need to run code on the client, I want to make sure that they download the least amount of code possible. And that was what I envisioned when I started on this code splitting and bundle optimization journey so that we can be competitive with you downloading an app on every dimension of the competition. And yeah, to your point, I think this is sort of like the secret, the open secret of like actually why the web over the long term is the killer platform for everything.

Yeah, love this take. And something I wanted to ask you, which is a little bit more personal, because I think something that shines across this conversation is how passionate you are about technology, even at a low level still, right? And you said you're still coding, you're making side projects in the weekend, but do you still find space and time to do technical work? For Vercel? Are you still coding on your day-to-day job?

I absorb a lot of information, so I don't code for my day job. I code in the sense of like, look, I can give you feedback on your product and I'll be able to— one of the things that I want to maintain until I die is I want to be able to think through first principles, through the underlying physics of the system, how long things ought to take. Right? So I think a big problem with being the CEO of a technical company, which these days is basically every company, is when your compass cannot be accurately calibrated. So you know that you have to go north. For example, every CEO would not dispute that their applications have to be fast. But what north? Like, are we going that way or like slightly left? Like, how do you calibrate with great precision, the needle of that compass. And so what I want to be able to do, not only because I think it makes me more effective as a leader, but also because it's very rewarding for me intellectually, is to actually be able to calibrate that needle really, really, really well, even without having to write code. You know the direction because you understand, all right, this system, the engineer is giving it to me. I open the website. I don't know, it takes 2 seconds to load the LCP. And I'm like, I know what's possible there. I know it could have been 100. And so the difference between 100 milliseconds and 2 seconds is significant, right? It's the difference between massive conversion changes. It's the difference between the kind of brand that we put out into the world. And so in order for me to give very high quality feedback to different product teams, to be able to actually sit down with some of the, some of the best business conversations I've had with prospects or partners have been because the CEO or CIO of a very large organization wants to understand what great looks like. They're going through digital transformation. A good example is we just closed a deal with a Fortune 500 company that builds developer tools for the real world, like from the physical world. And they've never had a really good direct-to-consumer relationship with their customers on the internet. If I told you the brand name, you would immediately recognize it because they're all over the world. But online is like they're amateurs. Hmm. And so who do they wanna partner with? They wanna partner with the CEO that is also high level like them.

Yeah.

That play it by ear. Or do they wanna partner with the CEO that knows exactly like what the recipe is, can give very good customer references, can pull up the phone and open an application on Vercel and say like, this is what you need. That I found has helped me close deals way more than trying to show up as a suit, you know, with my like tie and whatever. You'd be surprised about how effective it is to just like know things.

I love this. But has it always been easy to you to navigate this kind of role where you had to wear the hat of the CEO, but also retain this kind of unique value? I mean, I can think of the whole founder mode thread, you know, where by Brian Chesky and these all ideas about how founders scale their role in the company.

The Thunder Mode thing I think was incredibly helpful to the world because I think a lot of people like myself in this position sometimes also feel, you know, like, am I getting involved too much? Am I getting involved too little? Am I the real expert here? I mean, we just hire like people that have been at Google doing this for 20 years. Yes. And so you, you, you need to develop confidence in your taste, in the things that you know really well. You need to be able to be, to inquire and have honest conversations, intellectually honest conversations about the things that you don't know, but you're curious about. So you need to pick your battles. Of course, I think founder mode taken in the wrong direction could be catastrophic. Could be like not letting the experts cook. Yeah. Not Hiring people smarter than you in certain areas and things like that. Um, on the other hand, what's also been difficult is that when you go and talk to those CEOs of large fast food chains or consumer electronic manufacturers that are not in the weeds of the web, the day to day, you do need to change the way you talk and express your ideas. And so I think the challenge is that if I'm talking to an engineer, I need one set of tools and language. And if I'm talking to that other person, I need another set of tools and language. And so that can be challenging. It can be disorienting even, because you're like, am I getting lost in either direction?

I think it's ever-changing, but it's it's super exciting. So start from literally like open source, solo engineer to CEO of a large company and still retaining.

I was going to add with AI, I think so many more people are going to go through this journey. I think AI will make all of us full stack. I really believe that. Just this week, we had a situation with, I think it was Monday. I mean, time flies. Spain had those major blackouts, right?

Yes.

And one of my deepest infrastructure engineers that has never done frontend in his life.

Yeah.

Put out this really awesome visualization that I would say met the design standards of Vercel about the traffic drop that we saw in the, in, in our CDN network coming from Spain and Portugal, which was like 65% and 60% of traffic drop. And I thought, Oh, he must have worked with the design team on creating that artifact and whatever. And then I talked to him. No, he'd gone to v0. He threw in the CSV exported from our observability tool. He created this really awesome representation. And then we posted it on X and it has like a quarter of a million views. He was able to do things that were unthinkable 5 years, especially in the reactivity that is needed in this kind of world, like where like something happens and like you immediately are on the ball. Yeah. And so this is true also for technical people that want to develop business skills. Like, just go and talk to an AI and ask questions about the things they're missing, right? And vice versa. I think you're going to find that people that were not so technically versed can call bullshit on, like, an engineer says like, that's not possible, boss. I'm checking out for the week. Bye., and the boss says like, hey, AI, like, is this true? Like, and so, you know, it goes both ways. I think people are just going to get hopefully a lot more truth-seeking. This is my, one of my favorite Vercel values. When we hire someone, we optimize for truth-seeking. And so hopefully AI will take us into a world of everybody can seek truth and understand and just become smarter.

So yeah, one of my favorite quotes is by Ray Dalio, who said, you should replace the joy of being right with the joy of finding truth.

Beautiful.

And I love that. So thank you so much for coming on the show, Guillermo. It was a great chat.

This was super fun. Thank you, Luca.

Thank you so much. Thank you so much for listening. If you found this chat valuable, you can subscribe to the show on YouTube Apple Podcasts, Spotify, or your favorite podcast app. Also, please consider giving us a rating or leaving a review, as that really helps other listeners find the show. You can find all past episodes and learn more about the show at refactoring.fm. See you in the next episode.