SFG 19: Guillermo Rauch on dynamic web app development

‍

In this episode of the Startup Field Guide podcast, Wei Lien Dang chats with Guillermo Rauch, founder and CEO of Vercel. Guillermo was the CTO and co-Founder of LearnBoost and Cloudup, acquired by Automattic in 2013. He's the creator of several popular Node.JS open source libraries like socket.io, mongoose and slackin.

‍

Be sure to check out more Startup Field Guide Podcast episodes on Spotify, Apple, and YouTube. Hosted by Unusual Ventures General Partner Sandhya Hegde (former EVP at Amplitude), the SFG podcast uncovers how the top unicorn founders of today really found product-market fit.

‍

If you are interested in learning more about some of the themes and ideas in this episode, please check out the Unusual Ventures Field Guides on starting open-source companies, developing open-source customers, and building open-source GTM.

‍

TL;DR

‍

• Guillermo came up with the idea for Vercel because of the difficulty of deploying dynamic web applications and the complexity of using best-in-class front-end technologies. He saw the need for a globally distributed system for rendering front-end applications.
• Guillermo had always appreciated how open source can be virally and organically adopted. With Vercel, he realized that you could create open-source software targeted at engineers, while simultaneously building an enterprise business based on services and infrastructure that enable workflows and collaboration.
• Vercel discovered its path to product-market fit in the realm of e-commerce—when companies launched new products or marketing campaigns, their traditional infrastructure collapsed which offered Vercel the opportunity to create scalable, dynamic front-end experiences on top of existing legacy technologies. 
• Marketing to developers can be successful if you write content that is authentic, technical, and applicable to the pain points developers experience at work. Vercel’s most effective blog posts are product-focused and explain the company’s technology to developers.
• In Guillermo’s view, in the future, there is going to be a shift in investment from backend technologies to front-end. He also predicts that creating open-source technologies is going to become simpler because of “framework-defined infrastructures” that will create the infrastructure for new applications so developers are not burdened with this task.

‍

‍

Episode transcript

‍

Sandhya Hegde:

Today, we'll be diving into the story of Vercel, an open-source web development platform company with thousands of customers last valued at 2.5 billion dollars. We have with us today the CEO of Vercel, Guillermo Rauch, who was in fact the original creator of Next.js, an open-source front-end development web framework that powers React, an extremely popular JavaScript library for creating great user interfaces. Also with us today is my partner, Wei, who will be leading this interview. You'll be in great hands for the rest of the conversation.

Wei Lien Dang:

I'm super excited to be here with you, Guillermo, today, chatting about the story of Vercel and I'd love to start out by going back to 2015 when the company was first founded, and I think it was originally called ZEIT, actually. I'd love to hear how was the idea for Vercel born. What's the origin story of how you came up with the idea for the company?

Guillermo Rauch:

Yeah. I've been a front-end engineer for a huge part of my life. I became obsessed early on with what JavaScript enabled developers to do, which was fairly uniqu, that you could add interactivity to a page, you could make it real-time, you could make it self-updating. I created a bunch of open-source frameworks, I participated in many others. I started a company in the ad tech space here in the Bay Area in San Francisco that ended up being acquired by WordPress due to primarily our front-end competence. If I look back, we ended up pivoting the company from ad tech into instant file sharing and collaboration.

‍

When Matt Mullenweg, the founder of WordPress, took a look at it, he immediately made a bunch of connections on how they could improve a new perspective of investment within WordPress, which is front-end focused. Our technology started powering and making possible a set of innovations in the WordPress ecosystem like the new Gutenberg editor, those very interactive, real-time collaborative, basically block-based editing.

‍

When I left WordPress, I realized that the fundamental problems that WordPress had been having, which had to do with building up monolithically, with building up in languages that weren't JavaScript or TypeScript, which are needing to add more interactivity to their products, I thought it was something really interesting there. I had this idea for a framework for many, many years. In fact, if you go to my blog, rauchg.com, I wrote a blog post, I believe it was in 2014, called The Seven Principles of Rich Web Applications. I was obsessed with enumerating what are the things that make the best web applications work, what are the details, what are the decisions that they made.

‍

A lot of that was reverse engineering the best products of what we now call the giants of the web. I looked at how Amazon.com worked. I look at how Gmail worked. I look at how Google search worked. I looked at my whole experience in the years building different kinds of applications, and I wrote everything they had in common in seven principles. I gave lots of successful conference presentations about it, and what I ended up realizing is it didn't matter to how many conferences I traveled, how many people I told about these ideas, how many meetings I would get into, how many consulting jobs I would do. We needed a technology to make it possible to create these incredible web applications.

‍

So when I left WordPress, I had this idea: "I need to make the web faster. I need to make it more dynamic. I need to make it global." So I set out onto doing two work streams. One was creating a deployment platform that made it instant to deploy dynamic web applications. If you're an engineer, you know that hosting a static site has been pretty much a solved problem for many, many years. In fact, GitHub pages as a side hustle is a pretty good job with just hosting a static page, but a dynamic web application, which is really what has empowered amazon.com to be so good at selling you things, that was really, really, really hard. It required creating Kubernetes clusters and tons of infrastructure.

‍

I remember actually this moment that I had. I remember I was in my apartment in the marina in San Francisco and I needed to create the website for my startup, zeit.co, as you said, and just sitting down and starting up a Kubernetes cluster, which was a hot mess at the time, and it was open source. Again, we knew that it came from the giants of the web, Google. It was supposed to be good. It was supposed to be great, and maybe it was, but I spent weeks just setting up infra to deploy a page, again, using the best practices of the world. It's not that I could have used WordPress, I could have used Wix, I could have used Squarespace, but I wanted to build a real dynamic production-grade web application using the best practices.

‍

Interestingly enough, it didn't just happen to me with the infra, it also happened to me with the front-end engine or libraries that I wanted to use, in particular, React had also been open-sourced by Facebook at the time, now Meta. I went through the same epiphany with React. I was like, "Wait a second, just creating a page with React is taking me all this time configuring compilers and transpilers and minifiers and just lots of configuration." I was sitting down there to say, "I want to build with React components."

‍

So I think what's really made Vercel special is that it, in its genesis story, had this two very powerful requirements, one, insofar building the best possible web application with the latest and greatest front-and techniques, and then the other one that frankly I wanted to iterate very quickly, I wanted to deploy instantaneously, I wanted to grab a link, I wanted to share it with others with the ease of use that you would share a Google Doc or a Figma document. That was what it started it all and I got to work on both at slightly different times, but within the same space of the first few months of creating the company and the rest is history.

Wei Lien Dang:

That's amazing, Guillermo. I mean, I love the authenticity that you bring to solving those challenges and spotting the opportunity to do more both on, as you were saying, the front-end engine side, but also on the infra side. I find it fascinating that you were on the bleeding edge of these different technologies and what was available, and you still ran into so many pain points. You were using best-in-class front-end technologies both in terms of what came out of companies like Facebook and on the infra side, places like Google, and yet you identified these gaps. So I'm wondering if you felt something was missing or people just hadn't yet spotted where front-end development needed to go, how it needed to evolve?

Guillermo Rauch:

When you put it that way, I think it makes me realize that there was almost like a chain of miracles that had to happen to make this possible, right? To your point, I think a lot of that is about identifying the right time for the right opportunities, and ultimately how much do you bundle or buy versus build at the end of the day. I think that's something that founders should always be very, very, very thoughtful about.

‍

It's obvious looking back that it didn't make sense for me to rebuild React from scratch. In fact, I loved it, but democratizing it and making it useful for something that at the time it wasn't really optimizing for. So I'll get into that a little bit because I think it's really interesting. So when React was being created at Facebook, it started as this widget system. If you look at it from the point of view of a tree or a graft, it started from the leaves of the tree and then it was working its way up to basically power the entire trunk of the system.

‍

I was excited about using React for everything. I was excited by it powering the entire page rendering process. So that nobody was doing or very few people were doing or thinking about at the time. Again, it was about identifying the potential of a technology and extrapolating its ultimate consequences from a very early time.

‍

The other interesting thing, which is more technological, is React was going down this path of being a client-rendered technology because of the nature of how it was being introduced at Facebook. When it got open-sourced, a lot of people started using it that way, but I saw a lot more potential in transferring that rendering process to the cloud and making it be based on servers.

‍

That came from that research that I mentioned earlier. I had been thinking for so long about what makes google.com so fast, what makes amazon.com so fast. Almost universally, all of these sites that optimize for instantaneous page loads, that have a lot of money on the line, if Amazon becomes slower, everyone now knows the famous cliche of each hundred milliseconds was hurting their sales by 1% or so. Same with Google. They're fanatical about optimizing for obviously ad performance and click-through performance.

‍

So that's the other gap that I saw, which was more technological. So it gave me an opportunity to basically build in all of the white space that had been carved out by that initial open-sourcing of that particular technology.

‍

On the infrastructure side, I think something really similar happened, and perhaps it wasn't so obvious at the time, but when you're thinking about rendering front-end applications, when you're thinking about this idea of maximizing conversion, making things really fast, you're dealing with a global system. You're dealing with a system that can render pages as close as possible to the visitor. You're dealing with applications that might have multiple languages and render differently for multiple locations of the world.

So I took a different inspiration, I think. Even though things like Kubernetes existed, my obsession was that the new way of rendering applications had to work more as a globally distributed system. It was almost as if you had 30 clusters all over the world powering your application. I knew that that was going to be very, very, very hard for companies to do. Even if they staffed platform engineering teams, the fact that in order to become maximally fast, you were going to have to need a global footprint that the idea of a CDN and an application hosting provider were going to merge into the same infrastructure provider or the same kind of enabling technology. That was a spark that came from focusing primarily on this front-end ecosystem wedge. So that's what set out this co-development of both framework and infrastructure to meet the needs of the most demanding websites and applications.

Wei Lien Dang:

Yeah. What's really interesting, Guillermo, is you had this technical insight that melded both sides of it, and you understood both sides of it deeply to be able to pursue the opportunity in this space and wasn't necessarily to actually architect and build a solution for solving this dual-sided problem. Let me ask you. Was going open source always a no-brainer? You had React and on the infra side, things like Kubernetes were relevant. All of this is open source. Was that always something that just seemed obvious, and how did you get started with open source in terms of the initial project? How did you think about scoping what to first put out there and what are some of the advantages of open source that you were able to leverage early on?

Guillermo Rauch:

Yeah. In many ways it was obvious from recent experiences that I had had, but in many other ways, it wasn't obvious. So to give you some context, when I did my first startup, I was a very successful open-source author at that time, and I had built my entire career off of open-source. In a lot of podcasts, I always get asked about, "Tell us about your story because it's unique that you dropped out of high school, that you're completely self-taught, that you moved to the US from Argentina," and all of that really was enabled by open source for me because I got involved early on in open-source communities. I did a lot of learning. I built up my online resume off of these open-source projects. You mentioned a few earlier, but Socket.io is a good example of a real-time framework that I created that became really, really popular. In fact, one of the components of Socket.io, engine.io powers every real-time message in applications like Notion even today, or early on, it helped kick off the real-time components of when Microsoft was moving Word and spreadsheets and so on and Excel to the cloud and Office 365.

‍

So I had that taste of how enabling open source can be, how virally and organically adopted it can be, and it actually continues to be a very successful project. It has this AGI life of its own. I continue to encounter Socket.io in different places. Sometimes I tell people the story of when I reverse engineer the wifi portal of different flights that I'm on. There's a couple of airlines that their wifi portal is powered by Socket.io when you're in the air. So I had that taste of like, "Wow, you open source something, it takes the life of its own and it just grows and grows and grows." Of course, you have to put in a tremendous amount of work, needless to say.

‍

On the other hand, when I did my first startup, it wasn't an open-source dev tools company, and that's a part that is not obvious. At the time, I continued to see I had these two lives. I would come into work and I would do my application work. I was a CTO of that company, and concurrently, I kept investing in open source because it was such a great way of building networks and hiring engineers and putting the word out and developing a company profile. What was not obvious at the time, and that became more obvious things to companies like Mongo and HashiCorp and all these companies have been able to create businesses on top of open source.

‍

It wasn't clear to me 10 years ago, before I started Vercel, that you could marry these two things, you could create open-source software targeted at engineers, and at the same time you could create a huge business based on services and infrastructure and platforms that enable workflows and collaboration. So when I connected those dots, by the time I had left WordPress, it was very obvious. I knew that I was starting something from zero, from scratch. Open source was going to help me grow the awareness that I exist, and concurrently, I can build services that have a proven business model. I didn't have to innovate there.

‍

The last thing you want to do is innovate in ... You don't want to tie your groundbreaking ideas to something that is also groundbreaking I think from the way that you actually commercialize. You see this with ChatGPT, right? Yes, it's groundbreaking technology, but at the end of the day, it's being sold as a SaaS product. It has an API with some consumption pricing. It has a ChatGPT thing with a subscription. They're definitely not innovating there. So long story short, it was not on the way to becoming obvious by the time I started the company.

Wei Lien Dang:

You mentioned a lot of hard work to build the awareness and so on. After you launched Next.js, how did you go from there to driving adoption of the platform, which was first known as ZEIT and then eventually Vercel? What were some of the tactics, Guillermo, that you took that you found to be effective? How did you gain attention? How did you build your community into the vibrant, enthusiastic user base that you have today? Maybe along the way, if you could talk about how did you measure your progress? How did you know if you were on the right track given that with open source you put something out there and it can be challenging at times to understand who and how people are using it?

Guillermo Rauch:

I think luckily for me, the first idea that I became obsessed with was one command deployments that give you back a URL that you can share with your collaborators instantaneously. So it was purely from the I want to build a global infrastructure service that makes a collaboration for developers possible in the cloud that didn't exist before. Then I had the website and then I was like, "Holy crap! React is not really living up to its full potential." Then what really wasn't obvious at the time is that there were so many incredible opportunities, too, and we can get into that in a little bit, about making optimizations that require the integration of the two pieces that I think is ultimately responsible for a lot of our success in identifying that opportunity in the market, but that came through as a result of a lot of iteration.

‍

The core inspiration that I had was how can I build such a service. So, in some ways, the tricky part is when we released Next.js, and this is, again, the power of open source, and I'll get into why I think it's tricky, is it became an overnight success. People had a lot of pent-up demand for what it did, and it basically struck a number of chords at the same time. One was people were frustrated with configuring things like web back and bundlers, and they just want to sit down and create awesome web applications.

‍

Other people, especially in the enterprise, and this is something that's particularly unique about Next that I also would recommend folks keep in mind is Next was really good for enterprise buyers. Basically from day one because the other note that it hit was because it server renders, it's not just a developer experience play, it's not just like, "Oh," well, sometimes I call it ergonomics. It's the rubbery padding around the hammer that makes the life of the construction worker better. It's also that it's basically enabling you to build the most sophisticated buildings out there.

‍

Because you had those two requirements or two enablers, I would say, it was this, quote, unquote, "overnight success," again, predicated on years and years of research and writing all these essays and thinking very deeply about what makes the best applications and so on. Then obviously, the incredible enabler of React that without that engine I think none of that would've been possible, but the tricky part was, okay, the framework is growing so fast, you have to bootstrap infrastructure, which is very difficult to do at the same pace and at the same rate.

‍

So we took on the very hard work of doing both at the same time, and I would say we had really good demand for both, especially on the framework, but also the infrastructure from day one, but in the early days, it was very, very difficult to keep it in line or to basically scale while iterating in public.

‍

You see this a little bit, obviously, at a different scale in with different infrastructure, but it's very similar to what's happening with ChatGPT, where there's all this attention thrown onto it and there's no way that they would've been able to predict that that was going to happen. So you're building the product and the infrastructure concurrently.

‍

We had a lot of that in the first two years especially. One of the breakthroughs for us was this what is now known as a serverless operational model. The beginning of the company, Vercel was very broad in what it allowed you to deploy. As long as it was basically like a Unix process, it could do anything. It could run infinitely for as much time as you wanted. It could restart itself. It could expand and it could scale vertically in terms of memory allocation. It could have all these kind of properties that didn't narrow in on the very thing that we're having success with, which is this front-end delivery problem, which was where the demand for Next.js was coming from.

‍

So over the years, and this is the magic of creating great infrastructure, you started figuring out what are the right limits, what are the right constraints, what are the right defaults, what are the right APIs as well that I need to offer the developer in order for the system to be completely autonomous? That was my obsession at the time. I never wanted to do any special work for any customer. Of course, if you're an enterprise customer, I can give you more features. I can give you some automatic capabilities that provision all kinds of isolated things and whatnot, but my requirement, I'm really glad I was obsessed with this, is it doesn't matter if it's the largest team in the world or if it's a single developer. They both shared the same operational model.

‍

In order to accomplish that, that took a lot of work on both very clever API design, very interesting infrastructure that was created on top of what I call now the primitives of the cloud providers. Of course, we use cloud technology underneath, but we basically had to build that layer on top that made the technology just click for our customers' requirements, and because we were able to do that is that the business started scaling quite dramatically, especially around 2019, 2020. It just took off and it became this self-replicating thing where you would just sign up, start using it, deploy. It's very much autonomous in nature.

Wei Lien Dang:

Yeah, that's fascinating. The big focus of our show is finding product-market fit. From previous chats, Guillermo, you had such a deep understanding of what individual users were doing with the platform. From very early on, I remember you sharing how you were really obsessed with understanding what were the use cases, what were the capabilities, what were the features that really resonated with the early user base.

‍

I'm curious, among the first thousand users or so, you described building this very versatile, broad platform. Were there certain patterns that you saw in terms of what people got started with it to build? Were there particular app use cases that the early adopters consistently turned to, they were like, "Yup, Vercel's easily the best for X," and what was that X? I'm curious. Sometimes we think of it as what's the "aha" moment for a user when it comes to the product? I'm curious if there was something that you observed across the early community.

Guillermo Rauch:

The thing that consistently was, again, right under our nose, and it was fueled by the success of Next.js, but it required us to narrow in on in order for us to be successful was e-commerce. The most interesting things that people were building that had very clear commercially-viable paths were things that required really fast performance and really great iteration of velocity for somewhat constrained development teams, right?

‍

Again, everyone in the world is competing with Amazon.com, but who, especially everyone in the retail world, has the resources that Amazon.com has, especially with them having invented AWS and all that and having 20 years of experience in tuning their front-end compared to everybody else? So we started partnering more closely with a couple of startups that were doing things in the world of e-commerce, and we started to notice there are patterns and pains.

‍

Oh, it turns out that when you launch new products or you do large marketing campaigns or you email your entire user base, your traditional infrastructure is collapsing under its own weight. Oh, it turns out that you're using a slow backend. You're going to need some very interesting caching capabilities that go beyond what's being offered in the market in order to be able to create a dynamic experience that actually scales regardless of the existing or in spite of the existing legacy technology that that company has already bought.

‍

So it's a process of discovery. Oh, it turns out that you are more likely to succeed if you get added incrementally on top of what a company's already doing instead of trying to boil the ocean and propose that you rewrite all your software on top of this hot new platform, right? So those were some of the key unlocks for us.

‍

One of the things that we piggybacked on very early on was this idea of, "Look, the world is being rewritten in microservices. There is a rising API economy. A lot of the services that you used to write from scratch are now being offered as services." So that also helped a ton because now we started maturing our narrative around, "Use Vercel as this acceleration technology that you can add incrementally. It powers your entire front-end, and even though you can do some backendy things on us as well, look at your APIs and see if you can plug them in." Likely you could because of that market force that I just talked about, and now we have a very compelling narrative for being sold into an incremental project, being sold into an enterprise that has already made a bunch of decisions that cannot be — it doesn't matter how good your product is, your vision of the future that you're painting. You will have to coexist with all of the other software that is already powering that successful business, right?

‍

There's almost like a paradox there. You want to sell to an enterprise, right? Why do you want to sell to an enterprise? Well, because they have a lot of capital and they have interesting use cases. Well, how do they get there? Well, most likely, they got there by selling lots of successful products and services, and in 2020 forward, it's very likely that they have some footprint. So how do you come into that conversation? Do you come into that conversation saying, "Well, it's time to delete all the code, replace it with all this new risky code," or do you come in with, "Look, I understand what pain points you're having."

‍

I would have these conversations where I would find out that companies were launching massive projects using client-side rendering, and literally, their SEO would drop overnight. Projects literally had to get reverted. I was told about two different stories. One of the largest real estate companies in the world, one of the largest sneaker companies in the world, they had both unsuccessfully rolled out projects to try to use React, but because they were using it client side, they literally erased millions of dollars in value during their experiments in the form of lost sales or lost SEO.

‍

So you started narrowing in all those pain points. Those pain points later become your playbooks. You start finding out that, "Well, if company X ran into that issue, it's very likely that the next thousand companies will also run into that issue," or you can paint a picture of how you avoid that issue and you can now start developing that expertise. Those were some of the things that, again, even in the first thousand users, to your question, you could start picking apart those patterns, but the really difficult thing was in order for us to succeed, those thousand users didn't mean that we're going to focus our efforts equally among all of their use cases if that makes sense.

Wei Lien Dang:

Yeah, no, it definitely makes sense, Guillermo. Maybe to touch on how you go from developers to enterprise from a go-to-market standpoint, I mean, I think it's pretty well-known that developers, especially maybe the type that Vercel seeks to serve, they don't like to be marketed to in the traditional sense. I'm curious, how have you found effective ways to engage them and how have you built a team over time that's been able to do that? Because certainly, there's you, yourself, founder, thought leader, developer at heart, effectively archetype for the core person you're looking to target, but how have you thought about developer marketing at Vercel? What are some best practices you think exist today for how companies can engage that audience in a more modern rather than traditional sense?

Guillermo Rauch:

Yeah. I think marketing is a very loaded word because it encompasses such a broad range of activities that people perform when they work at companies, but I would actually say that people like being marketed too. I remember my first impression when I came to America, and it's almost reproducible to everyone that I know that comes to America, especially from Argentina. You go to the supermarket and you're like, "Holy shit! They have 300 kinds of water." In fact, I love water and I love testing out new ones and new brands and whatever. I love being marketed to by the grocery aisle of water at Whole Foods. In fact, I go there myself to be marketed to because I just love just walking around and seeing all the cool stuff that they have.

‍

I think developers are the same. Myself, I love, I mean, you what I do is I remember seeing this funny tweet like, "What do developers do when they go home from work?" They work on their side projects. Of course, that's not everybody, but as a developer myself, when I'm not working as a developer, I work as a developer on the things that I like working on as a developer.

‍

So I think that Whole Foods aisle exists for a lot of people in the form of Twitter and GitHub Explorer and Product Hunt and whatever, and that is the key. What they're shopping for is whatever they like on the terms and presentation that they like, on the ways of purchasing that they like, and so on and so forth. So if you're producing content that is authentic, that is technical, that focuses in on pain points that they can relate to, and this is, I think, the subtlety of what would make it, quote, unquote, "enterprise marketing" is, whatever it is that I'm teaching you has to be applicable to the pain points that you have at work.

‍

So sometimes I give folks that I advise the metaphor of: "I'm playing around with your technology during the weekend. I need to be able to see a plausible path that I get excited to bring it to work on Monday." So if you can find that duality, I think you can have something really interesting because folks always like playing around with new tech. I remember folks when Kubernetes first came out, they would start up their own personal cluster and load WordPress as a pod and MySQL as a pod. Horrible ideas today. In fact, even at the time, Kubernetes didn't recommend running your own database operators, but folks would tell you, "Use managed databases and, of course, decouple the monolith," and things like that, but folks were training themselves in their spare time for skills that could prove useful when they were going into the enterprise.

‍

I think if you can strike that balance, it's not always possible. There are certain categories of products. It might not be always possible, but I would argue that folks underestimate just how exciting it can be for developers to learn and get their hands on new technologies. If you can make it a delightful experience, then I think there is a very interesting path there to turn that product-focused, developer-focused marketing into something that's really effective.

‍

Another category there would be talking about your engineering, talking about how you build things, talking about the internals of technologies. Some of our most successful blog posts on Vercel are about pulling the layers apart of technology and telling you how they work. We did that with Turbo Pack, our new rust-based compiler that replaces web pack. We did that successfully with ... We actually have a blog post, and one of our most-read blog post is how our underlying infrastructure works. We give you all the details. We tell you how it works on the AWS side, how we've scaled it, and we will continue to do those write-ups because developers love to read those.

Wei Lien Dang:

I think it's very insightful, Guillermo, in terms of how to think about engaging with a developer audience. I saved the best for the last question, and this is probably my favorite one today, Guillermo, which is love to get your take on the market and where it is to date. There's a certain crowd that has long believed that open-source front-end frameworks couldn't be monetized, and you and the team at Vercel have certainly proved that not to be true.

‍

Now, is Vercel the exception or is this the start of a newer trend of large businesses built around front-end developer tools? I know that you have this notion of, going back to what you were sharing earlier throughout this conversation, around framework-defined infrastructure. What does that mean to you? What's your outlook on the market and the ecosystem? I would love to hear your perspective on that.

Guillermo Rauch:

Yeah. I'll start with addressing this massive movement that in some ways we helped pioneer, but is a very real thing today, which is this shift from interest and investment into back-end or I would call foundational infrastructure technologies into the front-end. I think that's going to lead to the creation of incredible companies. I'm an investor in the company, Clerk, which is doing this front-end and React-focused approach to authentication. There are companies like Recent that are doing a developer-focused and React-focused approach to email, transactional email, email marketing. So it's very exciting to see that because of this front-end cloud movement, we're going to see products that resonate with things that already existed, but the audience is different, the dev tools are different. It's probably way easier to integrate these products.

‍

I like the example of, I remember when Strike first came out, I was here in the valley and I was just so excited to see that the Hello World was a cURL command, and here's the rust API call. I think while that's an exciting way to still present a product today, the fact that now I can also give you a React component that already did basically the work of not just making the API calls, you can do the work of the UI and you can peel back the layers and you can completely edit that UI because it's open source. We're basically giving you more powerful and more ambitious building blocks to build faster. So I think it's going to be exciting to see what other parts of the cloud get re-expressed as part of this front-end point of view.

‍

Then to your other point, if a lot of these things are open source, how do you build a commercially viable business and how do you bring value to the world? That to me in my mind will continue to be very simple: You're selling infrastructure and you're selling some kind of workflow and some kind of way to enable people to collaborate more efficiently.

‍

So we also define this term that I'm very happy about because it's a great way to summarize all of the work that we've been doing over the past seven years, which is what we call framework-defined infrastructure. The fundamental idea is that instead of burdening you with the task of creating infrastructure before you can create your application, it's the act of writing and using a framework that outputs the infrastructure.

‍

This is doing a number of things that are really interesting. Number one, it gives you a very easy path to create a new technology that is open source on the framework side, it has a self-hosting option, of course, but now you can create an infrastructure business that is quite optimal for that kind of technology that you're creating.

‍

I mentioned earlier that if you really want to do a great job at delivering a front-end technology at scale, you have to create infrastructure that's global in nature. You have to create dozens of clusters all over the world, and you have to break down the technology into pieces that are independently deployable, and you have to scale them and so on. Now, because of framework-defined infrastructure, you can see a path of why we exist, why does Vercel exist. It would be so time-consuming, tedious, and difficult to provision all that for yourself and then maintain it for yourself.

‍

So it also brings a great deal of transparency to the work that you're doing. It brings a huge amount of agility to teams because now teams focus on the product. Frameworks have always focused on the product. You start creating your page, as I mentioned at the beginning of the story of why we even created Next.js and Vercel.

‍

The other really interesting thing that has done also as a side effect is local development for this cloud-native technologies that have been successful has basically been non-existent outside of frameworks. So of course, there's been a lot of progress in serverless technologies and managed offerings, but actually, very few of them have traditionally worked well while you're developing. AWS Lambda came out in 2014. It's still a basically unworkable experience to use it during local development, which is insane, right? As I mentioned, the world has optimized so much for infra and backend that even the most innovative pieces of technology don't have a way that developers can actually use them ergonomically.

‍

So I think this is a path for a lot of disruptions and innovations that are coming into the market. In fact, when we first published this blog was about Framework-defined Infrastructure, I got a bunch of pings from companies like Ingest, which is basically doing serverless workflows with a cohesive framework, especially targeting JavaScript developers. I got a ping from Daxter, who's basically creating a framework for doing ETL, and again, not having to worry about the infrastructure.

‍

I think we're going to continue to see a lot of innovation in this space, and it provides a very viable way for companies to monetize, and I think, like I mentioned, for consumers to understand the value they're getting and appreciate that you've gone through those troubles and created your technology that way.

Wei Lien Dang:

Well, it's super exciting, Guillermo. It's always a real pleasure to chat with you and hear you share about where you believe the ecosystem will go and how you'll lead us there. Thanks again for your time today. It was awesome to hear your story and the story of how Vercel found product-market fit, and look forward to the future of framework-defined infrastructure.

‍