Guillermo Rauch - Vercel, The Front End Cloud

we're obsessed with that customer experience. We call ourselves the frontend cloud because we propose that teams start building frontend first. Start with the customer, start with what do you want to deliver, start with how fast it is, how dynamic it is, and then work backwards into the technology.

Hello, welcome to the DevTools FM podcast. This is a podcast about developer tools, and the people who make 'em. I'm Andrew and this is my co-host Justin.

Hey everyone. Uh, we're really excited to have Guillermo Rauch on with us today. Guillermo, uh, you either directly or indirectly have really impacted a lot of the work that Andrew and I have done over the years, you know, be it your early development work, working on things like Socket.IO, or obviously now the work that Vercel enables. The webpage for our podcast is hosted on Vercel and sponsored by Vercel, which we appreciate. Um, so we're really excited to have you on. Uh, before we dive into the questions, would you like to tell our audience a little bit more about yourself?

Hey folks, I'm Guillermo. I'm the founder and CEO of Vercel and the creator of Next.js. And I'm really happy to be here because I love dev tools. And what Vercel does is provide developers with the best possible dev tools to build the fastest and most personalized web experiences on the internet. Cool.

So, uh, you, before Vercel, you had a long life as an open source person. Uh, you'd had a lot of really cool projects. You were the creator of Socket.io. I was visiting the MooTools page and I saw your old picture with, yeah, with your emo haircut. Fun to see. Uh, so from those days.

Yes, I was 16.

Oh, wow. Yeah. So from those days, how did, how did those tools and ideas shape where you went with your career and where Vercel is at today?

It's funny you mentioned Socket.io because a lot of people still get surprised that I created Socket.io and just say, holy shit. Vercel CEO created Socket.IO and it is surprising to me even in that, like, I didn't start a company for Socket.IO. Like that thing became so popular. I got lucky in that I think I hit really good timing with an open source solution for building real-time web applications. Real-time everything has sort of been the calling of my career. If you think about what we do today at Vercel is really making everything real-time, like make the deployment process feel real-time, iterating really quickly on projects. Socket.io was amazing because I was able to give the world a solution for something that everybody wanted, which was creating these real-time applications that are like chat-like, interactive, et cetera. And they couldn't do it at the time because web browser support was so lacking. So I kind of filled a very interesting niche of you want to build the future, web browsers don't support yet. So you need a developer experience that bridges the gap. So I learned a lot from that project. And one of the big takeaways was when I introduced Socket.io, The Hello World example was 7 lines of code and I kept code golfing it to just make the thing really easy to understand. So you could create a chat app or the backend for a chat app in like 7 lines of code. And people still love it for that reason. It's just so ergonomic. The developer experience is so great. And Mootools was very similar too. So if you think about jQuery and why projects like that became so popular, kind of the same pattern, right? Like the browser lacks some APIs or they're super clunky. What if we created a developer experience on top of that and distributed it as a library? So yeah, those were a huge inspiration for me as I, as I thought about creating Next.js and starting Vercel. You know, make saving, saving developers' lives, saving developers' time in their lives, I think is one of the most important things we can do for just like overall productivity, quality of life, creating better products, unleashing them into the world. But also I think the other thing that I couldn't do with Socket.io at the time was, can I create an infrastructure business on top that not only makes it easy to create things, but then for businesses, it gives them some ROI. It gives them a return on investment. Like if I buy this thing, if I give my developer this tool, it makes my business better in a measurable way.

So besides those projects, besides like Motul and Socket.io, when you're thinking up to sort of like the lead up of founding Zeit and then Vercel, like what was the sort of like pivotal projects in that journey?

One huge pivotal moment for me was realizing that we had React in open source. It was that I call it sometimes like the discovery of like a fundamental physics for developers because before React, it was really hard to collaborate and share units of work. We'll call them components for the sake of this conversation. And when I sat down to actually create something with React, that's when using investment terms, like I saw alpha because you have React. It's amazing in theory., but you want to put it to use. And the meme at the time was you need to take a PhD, get a PhD. And you've seen those funny photos of like a huge blackboard that is like 100 times the size of the person writing on it. And there's all these equations, like creating a project with React felt like that. And going back to what I was good at, right? Like with things like Socket.IO and Mood Tools. I'm good at creating a developer experience on top of systems that are very hard to get started with. That would be the kind of the, and democratizing those systems. So another metaphor I give people is React was like the discovery of a new awesome kind of engine, right? Like the steam engine or a Tesla electric engine, but what most people want is to get from point A to point B with a car. And so Next.js sort of filled the need of like, here's your car. It's going to get you places. It has an engine and some people are like huge fans. Like they get into the weeds, they pop up the frunk and they look at like, okay, what's in here. Most people don't really care as it turns out, especially as you go into like higher and higher levels of the kinds of companies that we talk to today. The reality is that they don't care that much about like each knob and each gear and each piece that went into constructing that engine. But more and more so, people are becoming aware that they need to make their developers productive and that hiring software developers is how they're going to actualize their businesses, especially for the largest companies in the world. And so we kind of, I was able to create a technology that kind of satisfied both needs and yeah, turned out pretty well, but I mean, embedded in a huge way to Meta open sourcing React and Google open source a bunch of other cool things like Kubernetes. We can get into the infra side of things if you want. But yeah, building on open source was a huge part of what makes us successful.

Yeah, I can see that theme of making a complicated tool simple with like the first product I knew from Zeit, uh, Now. You just run Now at your CLI and you get something pushed to the cloud. So since those days, uh, the company's changed a lot. It's got a different name, uh, a few different products. Like the first thing I actually associated you guys with was a terminal of all things.

That's awesome. I was just tuning my terminal yesterday and I was like, terminals are freaking awesome. And that's why we started that project. But it was a total side quest.

We'd like to thank our sponsor for the week, CodeCrafters. CodeCrafters makes programming challenges for experienced software engineers. If you're looking for a weekend project that takes you to the edge of your programming abilities, you gotta check 'em out. Uh, I've, I've worked through a few of their challenges now. Uh, I've done the Build Your Own Redis, which was a fun introduction. I leveled up to do the Build Your Own Git, which was a much larger challenge. One of the cool things about CodeCrafters is not only are you learning to do some programming language better and learn about some modern tool, you're also learning how to like sift through their code, sift through their docs, learn about their protocols, and really get to the bones of how these services actually work. I haven't started it yet, but my next challenge for the last leg of this sponsorship is to try to build my own SQLite. On the podcast, we've had lots of companies and products come on that are built around SQLite and all the cool things that it enables. So I think it would be pretty cool to get to learn how it actually works. If you ask me, learning like this is way better than grinding on some LeetCode. You actually get to build real skills and have fun while doing it. Besides the content, even the user experience is targeted towards experienced software developers. For example, instead of trying to tie you into a custom in-browser experience to edit code, CodeCrafters lets you use your IDE and your terminal. So you work as you normally would, push up to CodeCrafters, they run the tests, and they tell you if you pass. If you ask me, It's pretty cool. To try out CodeCrafters for yourself, visit codecrafters.io/devtools-fm. There you'll get a 40% discount and you'll be helping out the podcast a little bit too. That's not the only way to help out the podcast. You can become a paid member. If you become a paid member, you get access to our episodes a little bit early and you never have to hear any of these ads again. If you wanna sponsor DevTools FM, head over to devtools.fm/sponsor to apply. And with that, let's get back to the episode. So how would you explain the company Vercel to someone who doesn't know anything about it right now?

Yeah, I think every business today is becoming a digital business. That's like what we all agree upon, right? And becoming a digital business is actually really, really hard. Even though there's things like the cloud and AWS and like all this amazing open source knowledge, doing something at the level of the giants of the web. Like Amazon, Google, Meta is extremely hard, but that's today's battlefield. If you're a competitor of Amazon, like how do you get started in this world? Like deploying a massive storefront at planet scale that's really fast and personalized and ever improving. So we wanted to democratize the tools and infrastructure for businesses of all sizes to be able to get to that level of proficiency. And excellence. So Vercel is a platform for folks that have very ambitious ideas. If you want point and click, drag and drop and build a website for your restaurant, Vercel might not be the perfect fit. But if you're thinking about doing something ambitious on the internet, and when I talk about ambition, for example, Next.js, our open source framework, powers ChatGPT and it powers like actually a lot of the generative AI companies and a lot of the best storefronts in the world and nike.com. And so I'm really happy that we've been able to kind of find a good balance between ease of use, but also there's basically that's this infinite ceiling of how big you can get and how big you can build with our technology.

How has the vision of the company sort of changed over time? So what was it like when you like started? Did you have kind of an inclination of where you wanted to land or like? How's that evolved?

Yeah, it's a really good question because vision for the technology-wise, it actually hasn't changed that much. I sometimes go back. One of the cool properties of Vercel is that you can time travel to everything that you've deployed going years back. So I went back to like our earliest landing pages and I clicked, let's see the deployment for this landing page. And every time I read that stuff, I'm like, almost like impressed with myself because I'm like, wow, you were spot on. Like, I think for NOW, the product that you called, Andrew, we called it at the time, real-time global deployments was one of the first taglines. And it really hasn't changed that much. Like one of the things that we do really well today is that we allow this large merchants or huge companies to like launch globally, which is really hard. But it was very feature-based at the time. I think this is probably the most growth that I've experienced personally as a leader of this company is being able to actualize the messaging and make it resonate with more kinds of buyers, other kinds of developers, other kinds of architects, engineers, decision makers. So I think that's the biggest thing is like the vision never changed from a technology standpoint. We wanted to unleash this really fast tooling, this really great developer experience onto the world, take all the pain away from creating and scaling infrastructure. But today I give you sort of the ambition of creating the best products when I talk about what we do for you. And then we can get into the how. And I think that's a really healthy thing as the company grows because we change and adapt our tools. Today is Next.js, but for example, we also added through an acquisition, we acquired a company called Turbo. TurboRepo is a way of orchestrating large monorepos of code for really, really large builds. And we didn't start with that. And it didn't quite fit that tagline of like global deployments in some ways Turbo comes before the application framework, but it is in the same vein of like, here's tools that the giants of the internet use, like companies like Google. I think Google has the largest monorepo in the world, like billions of lines of code. And I wanted to democratize that technology. Now that technology again is a point solution in the service of you create amazing experiences on the internet, amazing products for your customers. I think As I keep reflecting on like what truly makes us different as a company and as a group of people on a DNA level is that we're obsessed with that customer experience. We call ourselves the front-end cloud because we propose that teams start building front-end first. Start with the customer, start with what do you want to deliver, start with how fast it is, how dynamic it is, and then work backwards into the technology.

Yeah, through that lens, it makes a lot of the things that you guys have done recently make a lot of sense. So like, One joke you might see about, uh, Vercel on Twitter is that they just wrap services, but that is exactly what you're saying is that we wanna wrap these services so that we've democratized them and make them easy to deploy for anybody. Cuz like on Vercel, I wanna run on the edge, I just export a variable. Oh, I wanna have, uh, a Postgres database, key-value store. Oh, right there, right off the shelf.

Yeah, that's a, that's a really good point. That's exactly how we architect. So first is what do you need to solve? What experience do you want to deliver? And then we work backwards into the how, and we abstract out the how from you so that you don't have to worry about it. So you, you hire us to do that, that sort of legwork. Um, and you judge us based on the experience. And by the way, the more we build out, the more I realize that we have to double down on this idea because the things that actually grow fastest that we put into the market and are most successful start that way. And then as they mature, as they get more usage, we can optimize them based on actual customer feedback. So every day I tell myself, keep building new things like we built this entire company. Even though now our infrastructure is like, has 7 years worth of work. If I'm building something new, I start with like, all right, developer experience, customer experience, then work backwards and iterate in public.

Yeah. I mean, that's such a powerful concept. And I think that, um, one of the things you, I mean, Vercel has become a big topic in the industry and there's a lot of people that talk about it. I mean, to your, to your credit, one of the things that you don't hear is that, oh, it's a bad experience. Like that's not something you hear. Like there are things that people will always complain about, about anything, but like the experience is not something that anybody. Has anything to say about. So I think that, like what you all have accomplished with the sort of just onboarding experience, the ease of development, the DX and everything is really powerful. I want to transition in that and ask you a little bit of a different question. So you said you're like front-end first, you're like focusing on that first customer experience and working backwards. And that makes a lot of sense, especially considering some of your hiring decisions. So one of the things that folks on Twitter had talked about kind of early on is you've hired a lot of people who work on these core frameworks. So you have Rich Harris on staff who works on Svelte. Uh, you have Sebastian on React. So what is your thinking around the, the hires in that area and like the framework levels?

Yeah, one of the key things for us is that even though we've seen tremendous success with Next.js, when I think 20 years into the future, I think about, you know, we'll be building the best tools for the job, whatever it takes. So as I mentioned earlier, it's about creating the best developer experience for the things that they need at the given time. And we've always been a multi-framework, multi-runtime company. In many ways, and this is an oversimplification, but if you've never heard of Vercel, using the famous Y Combinator X for Y explanation, we're like AWS for the frontend, right? And that means that you have to be, if you have that kind of aspiration, you have to be very versatile. You have to be very open-minded about what solutions, what languages, what technologies you support. So Svelte is a really great example of a completely different take. It's not React, it's a different syntax. It's maybe you can call it like signals versus, re-rendering or effects or whatever. And we wanted to have that point of view inside the company so that we can build the infrastructure that these frameworks connect to in a very versatile way. So the infrastructure has to be very flexible to serve the needs of as wide of a range as possible of people that want to build this way. So notice that we call it frontend. We do a lot of backend things, which sometimes like maybe throws people for a loop, but the thing is that when you build with Svelte, when you build with React, when you build with Next.js, when you build with Nuxt, you're building the customer-facing part of the experience. And that's where we want that flexibility. And then we want to build infrastructure that perfectly serves the needs of both the end users. So of course, when you go to like underarmor.com, it has to be really fast, but also we see the community of framework creators. As our customers as well. So we support like 40 frameworks, I believe, out of the box. So by getting the inputs of Sebastian and getting the inputs of Rich, we're building the best possible platform.

So recently, uh, you guys have been working towards a pretty big goal of React Server Components. Uh, I've read on Twitter that like, basically you guys are the people who invested in it and it's why it's really even a thing. So as a company, why did you guys think that RSC was the right bet to make?

Yeah, it's a great question because I created Next.js and I had a lot of influence over the design of the Pages Router. So to replace that is like killing your baby. You know, like I love my baby Pages Router. And I honestly do, like we've done incredible things with it. If you think about all the companies that we've served, one of the things that used to be really hard for, I think for the internet in general, but for Vercel was the customer builds something, they launch it and it needs to scale to like unknown amounts of traffic and it has to be very efficient. With Pages Router, we did more than just create a developer experience. We created a framework that had this novel integrations into cloud infrastructure like ISR that allowed people to scale to the tune of like, we went from like zero to tens of billions of requests per week as a platform. And a lot of that I owe to the fact that we created great integrations between Next.js and the cloud. So it's more than just, you get good feedback when you develop locally. When you deploy, you're orchestrating this global footprint of services and caching systems and functions and serverless and other things. So the framework worked really well, but it had a lot of really important limitations as I saw us going from that initial customer base to even more demanding software applications. So particularly one of the things that we did well with Next.js Stages Router is that we gave you a model for what we would call like hybrid static and dynamic pages. So the workload could be. Backed by a headless CMS, for example, or some e-commerce API. And then when we render, we can push that page to the edge. And then when the content changes, we can regenerate it at runtime. That was very important in our competition at the time with Gatsby. Gatsby was fully static generated, worked really well if you had 100 pages, went over that and all of a sudden, like, it just doesn't scale. But even our framework for the most demanding applications, the most dynamic, most personalized applications in the world was also too static. And what it resulted in was you had to use a lot of client-side JavaScript in order to actually deliver on things like A/B testing, feature flags, advanced personalization. Think of even what merchants are doing today. Like you go to Amazon. And then AI summarizes all the user reviews. So that level of dynamism required us to basically forego a lot of the assumptions that we put into the framework. For example, the entire page gets hydrated. Every single component has to get hydrated all at once. Uh, the fact that data fetching happens all in one function and you have to decide if the page is entirely static or entirely server rendered. So we needed something that actually kind of did what Next did in that competition with Gatsby. But again, although this time in competition with ourselves. In some ways, I think what's really interesting is that the biggest competitor of App Router is Stages Router. And it's weird because it's coming from the same vendor, but it's actually solving for all the pain points that we experienced with it. And sometimes I think what happens is that folks are not yet at that level. They haven't really seen the problems that the framework creates. Down the road. So it might be like, oh, maybe I'm just okay with Pages Router. And that's totally okay with because we still support it. But some of the things that we experience ourselves at Vercel with the limitations of Pages Router are actually what's directly influencing the adoption of React Server Components. So one of them, one of them that comes to mind is, um, our, our marketing website is built with Next.js in our Cloud Console is built with Next.js. When we want to do things like experimenting on a small portion of the page, Next.js Pages Router makes you almost go back to the thing that Next.js was trying to get rid of, which is you go back to like create React app in a fully client-rendered application. What we saw is that, you know, that has a tremendously negative impact on your Core Web Vitals. It actually makes engineers, and this goes even into like why Vercel exists, it makes engineers more fearful about experimenting with new ideas. One of the things that makes Vercel really special is just how experimental we are and how many things we try before we put it into the hands of customers with hundreds of flags at any given time that inform different new experiences that could be launched or could be killed. So we, we found that the previous version of our framework was kind of inhibiting that fearless evolution, fearless dynamism of the experience. And we needed something better. I think React Server Components is amazing because it's the first time that I've seen a comprehensive solution to that problem. And it's exciting for the open source community because going back to that idea of like Google, Meta, Amazon, they have internal versions of this. Amazon, for example, is very famous for they stream the experience. Like I always like showing people like if you zoom out, And you go to the product detail page of Amazon, you can see it coming to you in chunks. And what's fascinating is that to the end user, almost feels like a static page. That's how fast it is. They think it's cached. So that's kind of what I, I have my ambition for the, for App Router and React Server Components is it's so fast that you think it's the entire page is already computed for you and it's in some cache somewhere. In reality, it's being assembled and streamed on demand for you. And the content is exactly what you like. If you're a logged in visitor, what you've seen recently, your recommendations, what you left in the cart, things like that. And those are the things that, again, really move the needle for the kinds of people that are building these sophisticated sites.

So now that y'all have, I mean, you've been working on the sort of React Server Component integration, especially into Next for a long time. What are some exciting examples that you've seen of it?

Yeah, so the very first company that comes to mind is wap.com. They refactored from Pages Router to App Router and they were one of the earliest adopters of the framework. So they had not yet, they basically took a chance on it even when like, I believe it wasn't even stable yet. And what they told us is like, it kind of blew my mind, like doing like tens of millions of dollars in revenue through this faster version of their storefront with a tiny team. In fact, the, the fact that a startup could build something so complex, so dynamic, and put it out and just start receiving all this revenue kind of blew my mind. It was kind of that idea of like, can I give the infrastructure to people of what rivals amazon.com?, but democratize it for the rest of the world. So it was, it was, um, it was amazing to see, uh, early on. Another thing that's really exciting is our most successful customers have already migrated to App Router or in the process of migrating to App Router. And this is with us, again, giving you all of the options. You can stay where you are, you can adopt App Router, but typically as people mature their applications, they start hitting the limitations of Pages Router. And want to embrace React Server Components. Another thing that comes up a lot is it used to be impossible to sort of maintain the stability of your caches as you make releases. So let's say that I'm caching some content that comes from a CMS, and in the old world with ISR, I would push it, Vercel would cache it, I roll a new version of my site, All my caches are gone. So one of the very exciting things that React Server Components solved for us is this idea of decoupling the cache of the content and the backends from the actual page rendering. And of course, today you can still cache the entire page if you want, but the fact that we have this sort of like several layers after the page begins rendering is making it such that deploying doesn't take away from sort of what you've been building up until that time. So it means better stability for your backend. It means deploying more fearlessly because you're not sort of hurting the existing experience. Generally speaking, it's been exciting to see how everybody's adopting it for new projects as well. Figma.com, for example, just migrated from, interestingly enough, Gatsby into the Next.js App Router. So it's always awesome to see, to me, something I've always felt really proud of is the companies that I respect, the tools that I use, the folks that I want to work with choosing our tools, right? And so Stripe launched their Black Friday experience with the Next.js App Router, figma.com, a lot of awesome websites are adopting it and we continuously improve it.

Yeah, the App Router is really interesting. It just allows you to craft your code in such a different way. Like the thing that one of the tweets from you that made it click for me was somebody was like, What's the equivalent of like getStaticProps for, for this? And he's like that, you're just like, that's it. That's, that's the whole thing. You can use that, but at any point in the tree now. And I think that's just so simple and really unlocks a lot of cool things.

And you know what's funny? That was the, that was the top feature request for so many years. So something that's been great about React evolving in this way is that we would get all these feature requests and we literally could do nothing about them. So when we launched getStaticProps and getServerSideProps, people would say, awesome, I want exactly that. You nailed it, but please give it to me on the component level. And I was like, well, there's almost no way I can do this. Layouts is another great example of, we've been, people have been asking for layouts for so many years and we didn't do it for so many years because we couldn't find a way that it would be sustainably implemented. We knew what was coming ahead for React. We knew that, for example, suspense-based data fetching was coming. So we had to be very careful in how we added to React so that we wouldn't get in the way of its development. GetInitialProps, GetStaticProps, and GetServerSideProps were awesome innovations because they sat outside of React. They were like, okay, React, like now you take over. And in that way, Next.js Pages Router was a very collaborative player. So we route with Next.js, we do the initial data fetching with Next.js, and then we hand it off to React. What's happening today is that it's React itself that needs to fetch the data in order to create those very dynamic streamed experiences. React has to say, okay, now I have to fetch some data, or if it's not available, I have to give you the skeleton. So I flush and I stream the fallback. And now I continue down the tree. Oh, I need some more data. Maybe I can fetch it from the cache. Maybe I render, I stream it to the end user. So, um, in a nutshell, it's been amazing to see that React is taking more of the burden of what we Needed and in many ways couldn't implement. And now Next.js can sort of be, it's, it realized its full vision.

Yeah. In practice, it kind of just makes the whole API melt away. It's like, I don't, I'm not really caring about like using Next.js APIs to get my data. I don't really have to make API routes. That just, that's just part of my app and it all just kind of fits together.

Yeah. I remember a conversation I had with, um, Seb at one point and I was like, it's almost like he made me realize that. Creating an API and creating a React frontend were almost like two products. So if you think about, think about what comes to mind when you think world-class API, you think, well, like Stripe and their awesome documentation and how they authorize API calls and how they manage rate limits and observability. That's actually how you create a world-class API product. And then you create a product experience for an end user. What Next.js almost asks you to do is to partake in the journey of creating two products, even when your intention was to create one. So most people need to create just some application on the web. If we ask them to create an API, we're now asking them to create another application. And that comes with security implications. They have to like think about how to secure an API endpoint, which will get exposed to the entire internet. How to document it, open API specs, and so on and so forth. And then they need to worry about implementing their product. So to your point, it feels like the present is just very streamlined.

Yeah, I feel this really strongly. And my time at Oxide is like thinking about the API as like the entry point of the product was like a really strong motivator. And it is like, it's a very different mindset when you're crafting a big API. And we kind of see. And I like Next.js has really helped drive this is like, we see like originally is like, oh yeah, we'll either server-side render the whole page, you know, really old school style, or, you know, we'll break it apart and we'll do a SPA on an API. And then it like kind of got a little bit closer. It's like, okay, now we're building backends for frontends. And the model like scaled really well because people realized it's like they were just building APIs because it was like the thing to do. It's like, oh yeah, we need an API for our service. And then the APIs would bad because they just built it for their UI or whatever. They were the only people consuming their API. So it is nice.

That, that's actually one of the biggest pain points at Vercel that we felt is when we had to create very bespoke APIs just to make one frontend experience better. And we talk about this all the time. You're like, if I were to start this company over again, I would just start with the App Router. I would, you know, talk to my data layer in the most streamlined way possible. Because really what you're looking for in the early days is product market fit. You're not looking to create an API and then this frontend and this SPA and the customer doesn't care. So you need to get to market really fast. And that's what I'm excited about with this. To your point, it's almost like a return to the old way of building, but we're bringing the future into it. So it feels a lot like Ruby on Rails in some ways, which is how Shopify built into this magnificent business and GitHub built itself into a magnificent business and so many other examples. And yet it addresses a lot of their shortcomings, right? Like when I navigate GitHub, they retain no client state. Everything is this terrible link thing. They need more streaming. Clearly because sometimes it takes 10 seconds to go from page to page, whereas it could be very incremental. It doesn't feel like a SPA. It doesn't feel like instantaneous, like that feeling of a single page application that is already downloaded. On the other hand, you'll talk to those engineers and they'll tell you that's the most productive they felt in their entire career. They call it a monolith. I reject the premise that you need a monolith. I think what people really want is a monolithic way of building. I don't think they care that it's deployed into a 64-core bare metal for Excel instance in AWS or like it's an actual monolith, right? Like a mainframe, like an SAP app or whatever. But the experience of building has to approach a monolith. It has to approach a monolith in the data fetching code. Like, When I show people the code of React Server Components that looks like PHP, they're like, holy crap. Like, yes, thank you. But also why are you returning to 20 years ago? And that's when we need to explain, no, no, no, but we're bringing the future into it. And yeah, so I, some people get frustrated about the pendulum swings, but I've never seen the industry fully pendulum swing. It's not like we're building exactly like we were building with PHP, right? We have this rich client-side model now. We have interactivity, we have optimistic states, we have an entire ecosystem of client-side libraries and components, et cetera. But we did have to reclaim those benefits of the, I think DHH called it the majestic monolith. I think monolithic DX is what people ultimately want. And I'm very happy to sort of be contributing to delivering that to people.

So you, you mentioned earlier that like, oh, the way you guys build for Vercel is you set out with like a product vision, start at zero and see if the platform can support you. Uh, recently you guys have been experimenting with AI a lot and releasing a lot of like new AI features and libraries. So like, what's your vision for Vercel in the AI category and what do you guys plan to provide developers?

Yeah, in two words, our vision is what we call generative UI. We believe that there is a before and after with these LLMs in their ability to generate code on behalf of users. And these LLMs are actually particularly amazing at generating Tailwind, JSX, HTML, those kinds of things. So we created v0, which you can think of it as a generative UI design tool. You go in and you paste a screenshot or you talk to it and you generate UI. This is designed and conceived such that you save like 90% of your time. I don't believe, and there's a lot of chatter on Twitter about this, that like we're going to replace software engineers, but I think we're going to massively augment them with generative UI. And as we were creating this, we completely dogfooded Vercel. v0, and if you want to check it out, it's v0.dev, uses React Server Components for streaming. So as you, as we generate the UI, we give it to the client. Very important because AIs are pretty slow, especially when you have to do a lot of pipelines and very complex products. So you have to be able to render stuff as it becomes available. The other thing that's really interesting and why React Server Components got created is as the name implies, the server could have tens of thousands, millions of possibilities of components. In the conversation I talked about, you can have feature flags, you can have variants of components, and the client doesn't need to download a bundle that contains every single one of them. For example, the client doesn't need to download components in languages that it's not interested in speaking, right? So with React Server Components, we're able to actually create a product that not only can fetch from lots of different components, can even generate them on demand. So we dogfooded React Server Components, uh, Vercel KV, Vercel Postgres. This is an example of how we build our platform itself. We build products on it as first-class citizens from day one, pure Vercel. And along the way, one of the things that really stood out to people was this ability to The LLM responds with something and we can stream it to the client. And this stream is not just text like ChatGPT does or Markdown. We could stream any kind of visual and interactive representation. So recently we open sourced sort of the backing technology of B0 into what we call the AI SDK. So the AI SDK allows you to create your own generative UI experiences. Imagine you're Robinhood and you're creating a stock trading AI assistant and you want to say, what is the price of Apple? An old school, sort of old school from a year ago, an old school chat AI app would just say the stock of Apple is, well, first of all, they would tell you the stock of Apple is, I don't know, because I'm an LLM and blah, blah, blah. The AIs most recently gained this amazing capability called function calling. Now the AI can respond with like, let me call a function to get the price of Apple. The thing that Vercel has open sourced now into the AI SDK and is giving the world is the ability to not just call a function, but call a component. So we can grab the price of Apple, we can use React Server Components, we can inline the data fetching. So we can say, go and fetch the stock price from some stock API. In the meantime, we can stream a skeleton or the Suspense fallback so we can give the customer a really nice user experience. And then we give them the chart of the price of the stock over time. So we're basically democratizing all the infrastructure for you to go and build your own generative UI experiences. And I think this is going to have a profound effect into assistance that people build into their existing applications. Support experiences. A company called Klarna recently talked about it and went viral on the internet about saving $40 million by automating all this repetitive questions that we're getting from customers. And the other thing that I'm really excited about is that I talked earlier about how unless you're Apple, Google, Meta, reinventing yourself online has been really difficult. Think about, I don't know, PG&E, a company in the US that, uh, you know, has a website, but they don't have as many engineers as Meta does. And they're trying their best and like all of their world has kind of, has kind of become online first overnight. Or think about banks that used to work with like branches and people walking in to now they're again, like digital first companies. It's very possible that these companies will never get to the point where they build something as good as Instagram.com. And they'll just leapfrog creating some of that more of that traditional software with forms and lots of clicks and navigations, et cetera. And they just ship AI experiences. So I'm really excited about what generative UI can do for the folks that are kind of struggling on the internet. Another example I always think about is that mobile has been a nut that has been particularly tough to crack for most companies. There's like 10 or 20 native apps that we all use. And then there's a long tail of companies that wish they had an app, but getting the Swift developers, the Android developers, the React developers, and shipping on 3 platforms is really difficult. But if you can ship an AI experience because I opened pg&e.com and I'm like, I don't know why my bill is $300, please help me. Or my electricity just got cut off. I didn't get a notification. Please help me. So I think there's going to be a very long tail of user interactions that people are not going to solve with traditional software UI experiences. They're just going to leapfrog to AI. And hopefully this technology can help people get there.

Currently the SDK like only streams components you define though, right? So it's not like a full v0, like, oh, I asked it for weather and then it generated a full weather component for me with all the data fetching.

Yeah. That you didn't even know you had. That's kind of by design, by the way, because there's risk with like AI just creating like, imagine that you're Nike and we stream Adidas by mistake, right? So. Even the brand experience has to be carefully curated. But I do think that's next, right? Like, I believe we can tame this AIs enough that they can create completely novel results. Because ultimately what matters to you the most is the data, right? Like the data has to be accurate and accurately represented. The other thing that you want to infuse is your brand aesthetics and identity. The way to think about that is that that's almost like the system prompt. Your colors, who you are, your values, like, I don't know, like at Vercel, we like minimalist dark things, right? Like that's kind of like my system prompt. I do think we're going to get to the point where v0 and some of its fully rampant generative capabilities can also be safely embedded into the AI SDK. In the meantime, what people can do is sort of work on permutations or base components and then give some more freedom to the AI to call into them. And then a good example here would be a comparison table. You have more of a generic component and you can invite the AI to use it. So instead of just rendering text, the AI can say, well, now I can use a component here. Another way to think about it is you could produce diagrams on the fly where the SVG is completely generated by chaining two AIs together. You have the function call, first generate the React component to which it passes the properties and the properties are dreamt up by the AI., and then the other component uses another AI, potentially another model. So this model kind of lets you do ensemble of AIs, which is another thing that we discovered in the production of AI for, um, for v0. Most AI products at scale today, like little known fact perhaps, are assembling models together. So if I go to ChatGPT, I don't know if ChatGPT does this, but I know that a lot of ChatGPT-like products do. And say, um, I paste an image and I say, get me the strings. There's an optimization that you can do by routing that to a model that's good at that task. Translation is another example. Translate X to Y. Maybe I don't need the full power of the most powerful model that's out there, so I can route it to a more inexpensive model. So What's really cool about React Server Components is that in a way, they're also a great orchestrator of asynchrony. And this AI flows are very hard to actually write code for because sometimes they have to, for example, plan 10 steps and execute them in sequence, or they need to call 3 AIs in a row in order to produce a result while they're giving the customer feedback. So the AI is the case, not just generating UI, it's also letting you orchestrate these more complex flows of data.

It's a really, it's a really compelling use case. And I mean, I think the demos are fantastic and v0 is, is great. I want to go back to something that you said previously is that, you know, you think that the iteration of AI that we have, this is going to be really augmenting people. It's going to be. Making engineers be able to do more than they've been able to do before. And you're talking about like companies being able to sort of leapfrog these kind of awkwardly under-engineered apps that are insufficient for their users into something a little bit more tailored. The advancements of LLMs, especially recently, has been pretty fast, relative, or it seems really fast, and we've gained a lot of capabilities. What do you like, Where do you see this going the next, you know, 3 to 5 years? How do you see it projecting? I mean, is it going to be augmenting faster or is it like going to radically change how we interface with things? Like, what is it going to, what do you think that future looks like?

I think it's going to, I think it's going to continue to enhance our productivity at a rate that we haven't really seen with, let's call them like traditional developer tools, right? So an example is. If you want to make developers more productive with just Next.js, your options are somewhat limited, right? You can improve the development experience. You can make the HMR faster. You can make builds faster. We're doing all of those. We're rewriting the entire compiler into Rust for the dev mode experience is almost complete. But what's next after that? What do you do when you've rewritten it into Rust? You're right into like faster Rust. Like, you know, like you're kind of like out of options for like traditional developer experience methods. One thing that's particularly interesting to me is that what we need to be really good at is translating user intent into working software. That's what Copilot is already starting to show what's possible there. Because sometimes you just write a comment and then it suggests a completion. That is not a typical developer tool in the sense of like, there's no algorithm that anybody wrote. The way that it's optimized is not by, you know, making those algorithms faster, et cetera, et cetera. And the productivity gains are just massive, right? From incorporating these kinds of tools. So I think for a while, we're going to see that These two work streams are going to be done concurrently. We're going to continue to improve the performance of build tools. We're going to continue to improve the performance of runtimes, but we're going to hit diminishing returns. All of the alpha in developer experience will be in getting closer to the actual intent of the developer or designer. So we almost have to start earlier. Maybe you don't even use Next.js yet. I just have an idea for an app and I can draw it. So I remember it was this funny tweet that said like, with, with AIs and LLMs, it's almost like the return of the idea guy into prominence, right? Because the meme in Silicon Valley was like, there's always some person that wants to start a company and they don't bring much. They just have ideas. And then they have to find the technical co-founder. And the design co-founder and whatever. I want to make more and more that vision possible, not of a person that has not worked on their skills, but yes to having more and more ambition into what you can do full stack. I want to build that entire product from idea to global delivery on Vercel. And perhaps I don't, I'm not an expert in Tailwind. Perhaps I don't know what the right UX is for this data schema that I have. Or honestly, there's so much friction in doing that, that I perhaps would have not built the product. I find this with myself all the time with BeZero. People sometimes ask me, how come you post all this random stuff you build on Twitter? Like, when do you have time? And part of that is like, I have been doing this for 20 years. So I've become decent at like trying and deploying things. Obviously I'm dogfooding the product. I have some unfair advantages that if I ever get stuck, I not only can ask ChatGPT, but I can ask all these awesome colleagues that I have. But in reality, a lot of it is AI. I think 4 out of the last 5 products that I built, all of the UI has been built with v0. And for me, is that removing that writer's block. There is a writer block that happens with creating products and creating new user interfaces that is tremendous. And, uh, you all can probably relate to this experience. I'm going to self-own for a second. I run create-next-app. It shows me that page that says, welcome to Next.js, whatever. And then I delete all of it because I don't want it. Sorry, Next.js. Like, I don't want all your links. I don't want your logo, et cetera. And now what do I have? I have a blank page and it has Tailwind in there, which is awesome. But what do I, okay, I have to put something in there. And that's where I think v0 and all these tools are just going to be amazing because they're going to make us a lot more ambitious with starting new things, shipping new things, et cetera. You asked what are the capabilities that are coming to market that I think are going to take us to the next level. Okay, so what if I already have built the application? What if my application is millions of lines of code long? What if it's legacy? What if it's not Next.js App Router yet? Do I not get to play with all these toys? And I think the answer is all of the recent advancements like large context windows are going to make it possible to reason over much more code, essentially. So they're going to do wonders for things like migrating from Pages Router to App Router. We actually have done experiments internally with this where in order to migrate our own workload from Pages Router to App Router, we used AI for large chunks of it. We're going to be able to create, and this is coming soon for v0, we're going to be able to create code in the style of what you already prefer and what you already have. I think it's going to be huge because yes, it's cute to use V0 for something that new, but what if I already have a design system? And what if like not everyone can ship minimalist ShadCN looking code, right? Like what if I have to respect the brand identity of my company? So I still see all of that fundamentally, like the, all the stuff that's boring, clunky, uncreative. It's going to get done by AIs 100%. I sometimes think that it's useful to think of a lot of what we do as translation. When someone gives you a Figma, you're actually translating that into Tailwind. When you move from Pages Router to App Router, you're translating that. There's more of a cognitive overhead sometimes because like the conceptual model changes. But if I go with the translation route, I can at least give you the initial draft. The robot will say, all right, you're, I did all the legwork for the first part of the migration. Now you use your intelligence to determine, oh, we're going to use client-side rendering and client components over here. We're going to use server components over here. And like, I think the human will be sort of the editor in that process that continues to refine the code that the AI generates.

I, I totally agree. Like, uh, I, I love to liken my job to being a plumber. Uh, I, I see AI as just a really good wrench. Like, we invented a really good wrench that's really going to help a lot of plumbers and help more people become plumbers that weren't them before.

Absolutely. I, I love my job as a plumber too.

Well, let's talk about a different aspect of your job. Uh, so, uh, something that I can't help but notice is I see your name a lot on funding announcements for a bunch of different companies. So it seems like you've been, yeah, it's like a meme now.

I'm attached to so many memes. There's Vercel memes, there's funding announcement memes.

Yeah, for sure. You seem to be, uh, writing a lot of angel checks and I was curious about specifically, like, what do you look for when you're wanting to invest in a company?

The easy answer is I'm always looking for extraordinarily talented people. That have dedicated their life to the pursuit of sometimes specific thing that might be overlooked by others. One of my first angel checks was to a company called Auth0. And the founders were unreasonably dedicated to authorization and authentication. Like just let that sink in. Imagine convincing someone that's not in tech that that's an interesting thing to pursue. Every single waking hour of your life do. We're going to make login really great. Like, and yeah, so it's like, it's still part of like what I've always loved about Silicon Valley and why I fit in so well here, which is like, just power to the nerds. Like you want to nerd out for 10 years on auth. And it turns out that auth is going to power the, you know, it's going to be the digital entry point into every experience that matters on the internet. So you are also looking for that TAM, right? Going back to like plumbers in the real world is like, you're a locksmith. You're installing keys and locks into the world, into physical doors. But now in the digital realm, you can create an engine that does that with just 3 clicks. Oh, and it turns out that instead of there being billions of doors, there's going to be like trillions of doors. So you need that kind of like ridiculously sized market. You also need some kind of like controversial hypothesis. I think the very first thing that I thought about Auth0 was, wait a second, you're a 2-person company and everybody in the world is going to trust you with their auth? Like it almost made no sense. So you, you need things that make almost no sense. Whether Sam Altman like rolls into your room and says like, I'm going to invent AGI. It's like, sure, Sam, go away. No, you need something. And perhaps he doesn't quite get to like AGI is like science fiction or like that takes way too long, but he can deliver along the spectrum of that sort of controversial statement. Same goes, I think, for, uh, same was true for Auth0. So the technical sort of underpinnings and the unreasonable pursuit of that, you know, niche, you can call it, but it turns out it's not a niche. I think Paul Graham has become really good at this. We're like, you have to simultaneously appreciate it as a niche and then believe that that niche will grow to become a huge part of the global economy. Classic example here is Shopify starts with, um, the founder saying, I want to sell a snowboard. And there's no easy way to like, with two clicks, sell a snowboard. And then he went to knock on the doors of like lots of VCs. And they said, well, but I don't know if there's going to be that many people that need a small shop online. Turns out there were a lot. Uh, and so that's why it has to be sort of that duality of like, seems small because otherwise there's no alpha and everybody's in it. And then grows to be unreasonably big and obvious in retrospect. Bitcoin is actually another great example. When I first bought Bitcoin, I thought of it as my classic angel check. It's like, oh, I'll just put $20,000 into this thing. People say it's weird and like nobody will want it, but there is a chance and it seems like a niche that could get pretty big. And seeing is exactly like that sort of investment thesis.

Yeah, we just had Dani Grant on from JamDev and she asked us, how would you invest $100,000 into super early stage founders? And she said basically the same thing is that, uh, a person that is just wildly obsessed with a problem, uh, is a great start. And then you expanded upon it saying it's also an unreasonable goal. So unreasonable goal, uh, paired with like unreasonable drive to solve it.

You know, over the, over the last couple, it seems like to be accelerating now, like over the last couple quarters, I've been getting a lot of feedback from people that passed on Vercel early on. And they are now coming to me saying why, which I really appreciate. And most of the times it's something along these lines of like, it just seemed so unreasonable. Like the things you were saying, and I didn't even hear myself because like I'm embarrassed, like the over-aggrandized things that I was probably pitching at the time. Like, oh, we're going to take over the entire cloud. We're going to be the next AWS. And I was like, dude, you were some guy with a Shiba Inu in San Francisco. Like with a deck and you'd built nothing other than some open source project. So there was a bit of that in our story as well. And just like the sheer size of the ambition was pretty crazy. Like I think the thing that has also become a meme that I really appreciate is a lot of people like myself have gotten into this because we underestimated how difficult it was going to be. Because if you could show me a quick video, like a trailer when I started Vercel of the next 7 years and some of the lows and like late nights and pagers and whatever. I was like, huh, is it good? Is it going to take all of that? Like, holy shit. Like, let me, let me, let me get back to you, you know? So you kind of start with like this unreasonable goal and also a little bit of, and like, this is like this spoiler alert, like it's going to be so much harder and crazier than you believe. And you have to be signed up, you have to sign up for that. I think they, so you need someone that has the grit. Um, some people call it grindset now, like, and, and that's because again, they're just so obsessed. Danny is right. They're so obsessed with making that true and invested in some version of their ego into it as well. Like, I'm going to die before this succeeds. That was my thing. Like, I'm going to make this work at all costs. It was kind of my thinking.

That's awesome. So, uh, we've covered the, the, your answer, I think, to this question a little bit throughout the episode, but we like to ask it because it's a great way to sum up everything. So what do you think the future of frontend looks like? And, uh, what do you think the next wave of apps will be centered around? What will they look like?

Yeah, I think Things are going to get a lot easier. We hear a lot of the community feedback about the Next.js App Router and not only because of AI, but I think it's exciting that AI will fuel this. It's going to get a lot easier to write applications. A glimpse of this future is that kind of joke we made about like, we reinvented PHP, right? Well, we're all getting Lambos. We're like, oh, you just write some simple looking code that just queries a database and then the UI happens. I think we're going to deliver on that dream pretty soon here. It's already started and we're going to double down on that direction of just like making it unreasonably easy. But I think what was missing from that old approach is unreasonably fast, interactive, personalized, generative. I think generative UI will play a huge role into the future of software. It's going to get a lot easier for people to reach more users. I kind of talked about how difficult it is to meet every user, every device today, right? Like you have to develop a mobile app, an iOS app, an Android app, a web app, the API. I think we're going to go back a little bit almost to like that dream of the semantic web, like write once, deploy everywhere. And like what really matters is the semantics, the data, the content. The idea, because the rest is just automated by the computers. We're seeing a lot of interest in like the development of agents, right? And folks deployed Vercel in order to protect against agents. Like a lot of folks are paranoid over like how they're in the age of AI, their content is just being scraped and misused, et cetera. But also the reality is that with agents, we can make any system interoperable, even without you explicitly programming it interoperability. We kind of talked about why like it was too effortful to create an API route and then create your frontend. What if all you are is frontend? Because you're all you care about is the customer experience. The interoperability between systems can be automated. Everything will be an API in some, in some senses. So I think empowering the future with AI, empowering developers with AI, and also helping companies become AI companies. Especially when they're struggling to deliver in today's software challenges in the world of today is part of our mission now, and we're excited to deliver on it.

I'm excited to see you accomplish the goal. It's a, it's a big goal you guys got, but it definitely speaks to the unreasonable goals.

We'll get there.

So that's it. All we have for questions. Thanks for coming on. This was a great episode. Me and Justin have been waiting for this one for a while, and it was an amazing chance to get to talk to you.

Thank you so much. I really had fun with it.

Yeah, thanks so much, Guillermo. Uh, you're, I mean, we're big fans of the work that Vercel has done and continues to do. So yeah, wish you all the best of luck and excited to see what comes next.