About Guillermo

• Vercel: https://vercel.com/
• v0.dev: https://v0.dev
• Personal website: https://rauchg.com
• Personal twitter: https://twitter.com/rauchg
  
  

Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I don’t talk a lot about front-end on this show, primarily because I am very bad at front-end, and in long-standing tech tradition, if I’m not good at something, apparently I’m legally obligated to be dismissive of it and not give it any attention. Strangely enough, I spent the last week beating on some front-end projects, and now I’m not just dismissive, I’m angry about it. Here to basically suffer the outpouring of frustration and confusion is Guillermo Rauch, founder and CEO of Vercel, but also the creator of Next.js. Guillermo, thank you for joining me.

Guillermo: Great to be here. Thanks for setting me up with that awesome intro.

Corey: It’s true, if I were talking to someone who looked at what I’ve done, and for some Godforsaken reason, they wanted to follow in my footsteps, well, that path has been closed, so learning a bunch of Perl early on and translating it all to bad bash scripts and the rest, and then maybe picking up Python isn’t really the way that I would advise someone getting started today. The de facto lingua franca of the internet is JavaScript, whether we like it or not, and I would strongly suggest that be someone’s first language despite the fact that I’m bad at it, I don’t understand it, and therefore it makes me angry.

Guillermo: Yeah, it’s so funny because it sounds like my story. And my personal journey was, when I was a kid, I had a—I knew I wanted to hack around with computers, and reverse engineer them, and improve them, and just create my own things, and I had these options for what programming language I could go with. And I tried it all: PHP, Perl, [Mod PHP 00:02:12], [Mod Perl 00:02:13], Apache, LAMP, cgi-bin folders, all the whole nine yards. And regardless of what back-end technology I used, I encountered this striking fact, which was… the thing that can make your product really stand out in a web browser is typically involving JavaScript in some fashion. So, when Google came out with suggestions as you would type in a search box, my young kid Argentinian brain blew up. I was like, “Holy crap, they can suggest, they can read my mind, and they can render suggestions without a full page refresh? What is that magic?”

And then more products like that came out. Google Docs, Gmail Chat, Facebook’s real time newsfeed, all the great things on the internet seemed to have this common point of, there’s this layer of interactivity, real-time data, customization, personalization, and it seems uniquely enabled by the front-end. So, I just went all in. I taught myself how to code, I taught myself—I became a front-end engineering expert, I joined some of the early projects that shaped the ecosystem. Like, there was this library called MooTools, and a lot of folks might not have heard that name. It’s in the annals of JavaScript history.

And later on, you know, what I realized is, what if front-end can actually be the starting point of how you develop the best applications, right, rather than this thing that people, like, reluctantly frown upon, like yourself. I mention that as an opportunity rather than a diss because when you create a great front-end experience, now the data has proven you run a better business, you run a more dynamic business, probably are running an AI-powered business, like, all of the AI products on the planet today are using this technology to stream text in front of your eyes in real time and do all this awesome things. So yeah, I became obsessed with front-end, and I founded this company Vercel, which is a front-end cloud. So, you come here to basically build the best products. Now, you don’t have to build the back-end, so you can use back-ends that are off the shelf, you can connect to your existing back-ends, and we piggyback on the world’s best infrastructure to make this possible, but we offer developers a very streamlined path to create these awesome products on the internet.

Corey: I have to say that I have been impressed when I’ve used Vercel for a number of projects. And what impresses me is less the infrastructure powering it, less the look at how performance it is and all the stuff that most people talk about, but as mentioned, I am not good at front-end or frankly programming at all. And so, many products in this space fall into the very pernicious trap of, “Oh, well, everyone who’s using this is at least this tall on the board of how smart you are to get on the amusement park ride.” So, I feel that when I’m coming at this from a—someone who is not a stranger to computers but is definitely new to this entire ecosystem, everything just made sense in a way that remarkably few products can pull off. I don’t know if you would call that user experience, developer experience, or what the terminology you bias for there is, but it is a transformational difference.

Guillermo: Thank you. I think it’s a combination of things. So, developer experience has definitely always been a focus for me. I was that weird person that obsessed about the CLI parameters of the tool, and the output of the tool, and just like how it feels for the engineer. I did combine that with—and I think this is where Vercel really stands out—I did combine that with a world-class infrastructure bit because what I realized after creating lots and lots of very popular open-source projects—like, one is called Socket.io, and other one called Mongoose—DX, or developer experience, in the absence of an enticing carrot for the business doesn’t work. Maybe it has some short term adoption, maybe it has raving fans on Twitter or X [laugh], but at the end of the day, you have to deliver something that’s tangible to the end-user and to the business.

So I think Vercel focusing on the front-end has found a magical combination there of I can make the developer lives easier. Being a developer myself, I just tremendously empathize with that, but it can also make more profit for the business. When they make your website faster and render more dynamic data that serve as better recommendations for a product on e-commerce or in a marketing channel, I can help you roll out more experiments, then they make your business better, and I think that’s one of the magical combinations there.

The other thing, frankly, is that we’d started doing fewer things. So, when you come to Vercel, you typically come with a framework that you’ve already chosen. It could be Next.js, it could be View, [unintelligible 00:07:18], there’s 35-plus frameworks. But we basically told the market, you have to use one of these developer tools in order to guide your development.

And what companies were doing before—I mean, this almost seems obvious in retrospect, that we would optimize for her certain patterns and certain tools—but what the market was doing before was rolling out your own frameworks. Like, every company was, basically—React, for example, is a very popular way of building interfaces, and our framework actually is built on top of React. But when I would go to and talk to all these principal engineers that all these companies, they were saying, oh yeah, “We’re creating our own framework. We’re creating our own tools.” And I think that to me now feels almost like a zero interest rate phenomenon. Like, what business do you have in creating frameworks, tools, and bespoke infra when you’re really in the business of creating delightful experiences for your customers?

Corey: What I think is lost on a lot of folks is that if you are trying to learn something new and use a tool, and the developer experience is bad, the takeaway—at least for me and a lot of people that I talk to is not, “Oh, this tool has terrible ergonomics. That’s it’s problem.” Instead, the takeaway is very much, “Oh, I’m dumb because I don’t understand this thing.” And I know intellectually that I am not usually the dumbest person in the world when it comes to a particular tool or technology, but I keep forgetting that on a visceral level. It’s, “I just wish I was smart enough to understand that.”

No, I don’t. I wish it was presented in a way that was more understandable and the documentation was better. When you’re just starting out and building something in your spare time, the infrastructure cost is basically nothing, but your time is the expensive part in it. So, if you have to spend three hours to track down something just because it wasn’t clearly explained, the burden of adopting that tool is challenging. I would argue that one of the reasons that AWS sees some of the success that it does is not necessarily because it’s great so much as because everyone knows how it breaks. That’s important.

I’m not saying their infrastructure isn’t world-class—please, don’t come at me in the comments on this one—but I am saying that we know where its sharp edges are, and that means that we’re more comfortable building with it. But the idea of learning a brand-new cloud with different sharp edges in other areas. That's terrifying. I’d rather stick with the devil I know.

Guillermo: Exactly. I just think that you’re not going to be able to make a difference for customers in 2023 by creating another bespoke cloud that is general purpose, it doesn’t really optimize around anything, and you have to learn all the sharp edges from scratch. I think we saw that with the rise of cloud-native companies like Stripe and Twilio where they were going after these amazingly huge markets like financial infrastructure or communications infrastructure, but the angle was, “Here’s this awesome developer experience.” And that’s what we’re doing with Vercel for the front-end and for building products, right? There has to be an opinionated developer experience that guides you to success.

And I agree with you that there’s really, these days in the developer communities, zero tolerance for sharp edges, and we’ve spent a lot of time in—even documentation, like, it used to be that your startup would make or break it by whether you had great documentation. I think in the age of frameworks, I would even dare say that documentation, of course, is extremely important, but if I can have the tool itself guide you to success, at that point, you’re not even reading documentation. We’re now seeing this with AI and, like, generative AI for code. At Vercel, we’re investing in generative AI for user interfaces. Do you actually need to read documentation at that point? So, I think we’re optimizing for the absolute minimal amount of friction required to be successful with these platforms.

Corey: I think that there’s a truth in that of meeting customers in where they are. Your documentation can be spectacular, but people don’t generally read the encyclopedia for fun either. And the idea of that is that—at least ideally—I should not need to go diving into the documentation, and so many tools get this wrong, where, “Oh, I want to set up a new project,” and it bombards you with 50 questions, and each one of these feels pretty… momentous. Like, what one-way door am I passing through that I don’t realize the consequences of until I’m 12 hours into this thing, and then have to backtrack significantly. I like, personally, things that bias for having a golden path, but also make it easy to both deviate from it, as well as get back onto it. Because there’s more than one way to do it is sort of the old Perl motto. That is true in spades in anything approaching the JavaScript universe.

Guillermo: Yeah. I have a lot of thoughts on that. On the first point, I completely agree that the golden path of the product cannot be documentation-mediated. One of the things that I’ve become obsessive about—and this is an advice that I share with a lot of other startup founders is, when it comes to your landing page, the primary call to action has to be this golden path to success, like, 2, 3, 4 clicks later, I have to have something tangible. That was our inspiration.

And when we made it the primary call to action for Vercel is deploy now. Start now. Get it out now. Ship it now. And the way that you test out the platform is by deploying a template. What do we do is we create a Git repo for you, it sets up the entire CI/CD pipeline, and then at that point, you already have something working, something in the cloud, you spent zero time reading documentation, and you can start iterating.

And even though that might not be the final thing you do in Vercel, I always hear the stories of CTOs that are now deploying Vercel at really large scale, and they always tell me, “I started with your hobby tier, I started with free tier, I deployed a template, I hacked on a product during the weekend.” Now, a lot of our AI examples are very popular in this crowd. And yeah, there’s a golden path that requires zero documentation. Now, you also mentioned that, what about complexity? This is an enterprise-grade platform. What about escape hatches? What about flexibility? And that’s where our platform also shines because we have the entire power of a Turing-complete language, which is JavaScript and TypeScript, to customize every aspect of the platform.

And you have a framework that actually answered a lot of the problems that came with serverless solutions in the past, which is that you couldn’t run any of that on your local machine. The beauty of Vercel and Next.js is we kind of pioneered this concept that we called ‘Framework Defined Infrastructure.’ You start with the framework, the framework has this awesome property that you can install on your computer, it has a dev command—like, it literally runs on your computer—but then when you push it to the cloud, it now defines the infrastructure. It creates all of the resources that are highly optimal.

This creates—basically converts what was a single node system on your computer to a globally distributed system, which is a very complex and difficult engineering challenge, but Vercel completely automates it away. And now for folks that are looking for, like, more advanced solutions, they can now start poking into the outputs of that compilation process and say, “Okay, I can now have an influence or I can reconfigure some aspects of this pipeline.” And of course, if you don’t think about those escape hatches, then the product just ends up being limiting and frustrating, so we had to think really hard about meeting both ends of the spectrum.

Corey: In my own experimentations early on with Chat-Gippity—which is how I insist on pronouncing ChatGPT—a lot of what I found was that it was a lot more productive for me to, instead of asking just the question and getting the answer was, write a Python script to—

Guillermo: Yes.

Corey: Query this API to get me that answer. Because often it would be wrong. Sometimes very convincingly wrong, and I can at least examine it in various ways and make changes to it and iterate forward, whereas when everything is just a black box, that gets very hard to do. The idea of building something that can be iterated on is key.

Guillermo: I love that. The way that Vercel actually first introduced itself to the world was this idea of immutable deployments and immutable infrastructure. And immutable sounds like a horrible word because I want to mutate things, but it was inspired by this idea of functional programming where, like, each iteration to the state, each data change, can be tracked. So, every time you deploy in Vercel, you get this unique URL that represents a point-in-time infrastructure deployment. You can go back in time, you can revert, you can use this as a way of collaborating with other engineers in your team, so you can send these hyperlinks around to your front-end projects.

And it gives you a lot of confidence. Now, you can iterate knowing that before things go out, there’s a lot of scrutiny, there’s a lot of QA, there’s a lot of testing processes that you can kick off against this serverless infrastructure that was created for each deployment. The conclusion for us so far has been that our role in the world is to increase iteration velocity. So, iteration speed is the faster horse of the cloud, right? Like, instead of getting a car, you get a faster horse.

When you say, “Okay, I made the build pipeline 10% faster,” or, “I brought the TLS termination 10% closer to the visitor, and, like, I have more [pops 00:17:10],” things like that. That to me, is the speed. You can do those things, and they’re awesome, but if you don’t have a direction—which is velocity—then you don’t know what you’re building next. You don’t know if your customers are happy. You don’t know if you’re delivering value. So, we built an entire platform that optimizes around, what should you ship next? What is the friction involved in getting your next iteration out? Is launching an experiment on your homepage, for example, is that a costly endeavor? Does it take you weeks? Does it take you months?

One of the initial inspirations for just starting Vercel and making deployments really easy was, how difficult is it for the average company to change in their footer of their website is this copyright 2022? And you have—it's a new year. You have to bump it to copyright 2023. How long do you think it takes that engineer to, A, run the stack locally, so they can actually see the change; deploy it, but deploy to what we call the preview environment, so they can grab that URL and send [it to 00:18:15], Corey, and say, “Corey, does it look good? I updated [laugh] I updated the year in the footer.”

And then you tell me, “Looks good, let’s ship it to production.” Or you tell me, “No, no, no, it’s risky. Let’s divide it into two cohorts: 50% of traffic gets 2022, 50% of traffic gets 2023.” Obviously, this is a joke, but consider the implications of how difficult it is and the average organization to actually do this thing.

Corey: Oh, I find things like that all the time, especially on microservices that I built to handle some of my internal workflows here, and I haven’t touched in two or three years. And okay, now it’s time for me to update them to reflect some minor change. And first, I wind up in the screaming node warnings and I have to update things so that they actually work in a reasonable way. And, on some level, making a one-line change can take half a day. Now, in the real world, when people are working on these apps day-in and day-out, it gets a lot easier to roll those changes in over time, but coming back to something unmaintained, that becomes a project the longer you let it sit.

Part of me wishes that there were easier ways around it, but there are trade-offs in almost any decision you make. If you’re building something from the beginning of, well, I want to be able to automatically update the copyright year, you can even borderline make that something that automatically happens based upon the global time, whereas when you’re trying to retrofit it afterwards, yeah, it becomes a project.

Guillermo: Yeah, and now think, that’s just a simple example of changing a string. That might be difficult for a product engineering in any organization. Or it may be slow, or it may be not as streamlined, or maybe it works really well for the first project that that company created. What about every incremental project thereafter?

So, now I said—let’s stop talking about a string, right? Let’s think about you’re about an e-commerce website where what we hear from our customers on average, like, 10% of revenue flows through the homepage. Now, I have to change a primary component that renders on the hero of the page, and I have to collaborate with every department in the organization. I have to collaborate with the design team, I have to collaborate with marketing, I have to collaborate with the business owners to track the analytics appropriately. So, what is the cost of every incremental experiment that you want to put in production?

The other thing that’s particularly interesting about front-end as it relates to cloud infrastructure is, scaling up front-end is a very difficult thing. What ends up happening is most front-ends are actually static websites. They’re cached at the edge—or they’re literally statically generated—and then they push all of the dynamism to the client side. So, you end up with this spaghetti of script tags on the client, you end up accumulating a lot of tech debt in the [shipping 00:20:56] huge bundles of JavaScript to the client to try to recover some dynamism, to try and run these experiments. So, everyone is in this, kind of, mess of the yes, maybe we can experiment, but we kind of offloaded the rendering work to the client. That in turn makes me—basically, I’m making the website slower for the visitor. I’m making them do the rendering work.

And I’m trying to sell them something. I’m trying to speed up some processes. It’s my responsibility to make it fast. So, what we ended up finding out is that yes, the cloud moved this forward a lot in terms of having these awesome building blocks, these awesome infrastructure primitives, but both in the developer experience, just changing something about your web product and also the end-user experiences, that web product renders really fast, those things really didn’t happen with this first chapter of the cloud. And I think we’re entering a new generation of higher-level clouds like Vercel that are optimizing for these things.

Corey: I think that there’s a historical focus on things that have not happened before. And that was painful and terrible, so we’re not going to be focusing on what’s happening in the future, we’re going to build a process or a framework or something that winds up preventing that thing that hurt us from hurting us again. Now, that’s great in moderation, but at some point—we see this at large companies from time-to-time—where you have so much process that is ossified scar tissue, basically, that it becomes almost impossible to get things done. Because oh, I want to make that—for example, that one-line change to a copyright date, well, here’s the 5000 ways deploys have screwed us before, so we need to have three humans sign off on the one-line change, and a bunch of other stuff before it ever sees the light of day. Now, I’m exaggerating slightly, just as you are, but that feels like it acts as a serious brake on innovation.

On the exact opposite side, where we see massive acceleration has been around the world of generative AI. Yes, it is massively hyped in a bunch of ways. I don’t think it is going to be a defined way that changes the nature of humanity the way that some of these people are going after, but it’s also clearly more than a parlor trick.

Guillermo: I’m kind of in that camp. So, like you, I’ve been writing code for many years. I’m pretty astonished by the AI’s ability to enhance my output. And of course, now I’m not writing code full time, so there is a sense of, okay because I don’t have time, because I’m doing a million things, any minute I have seems like AI has just made it so much more worthwhile and I can squeeze so much more productivity out of it. But one of the areas that I’m really excited about is this idea of generative UI, which is not just autocompleting code in a text editor, but is the idea that you can use natural language to describe an interface and have the AI generate that interface.

So, Vercel created this product called v0—you can check it out at v0.dev—where to me, it’s really astonishing that you can get these incredibly high quality user interfaces, and basically all you have to do is input [laugh] a few English words. I have this personal experience of, I’ve been learning JavaScript and perfecting all my knowledge around it for, like, 20 or so years. I created Next.js.

And Next.js itself powers a lot of these AI products. Like the front-end of ChatGPT is built on Next.js. And I used v0 to create… to basically recreate my blog. Like, I created rauchg.com, I deployed it on Vercel, but every pixel of that UI, I handcrafted.

And as we were working on v0, I said okay, “I’m going to challenge myself to put myself back in the shoes of, like, I’m going to redesign this and I’m going to start over with just human language.” Not only did I arrive to the right look and feel of what I wanted to get, the code that it produced was better than I would have written by hand. Concretely, it was more accessible. So, there were areas of the UI where, like, some icons were rendered where I had not filled in those gaps. I just didn’t know how to do that. The AI did. So, I really believe that AI will transform our lives as [laugh] programmers, at least I think, in many other areas in very profound ways.

Corey: This is very similar to a project that I’ve been embarked on for the last few days where I described the app I wanted into Chat-Gippity and follow the instructions, and first, it round up point—sending me down a rabbit hole of the wrong Framework version that had been deprecated, and whatnot, and then I brought it all into VS Code where Jif-Ub Copilot, it kept switching back and forth between actively helpful, and ooh, the response matches publicly available code, so I’m not going to tell you the answer, despite the fact that feature has never been enabled on my account. So yeah, of course, it matches publicly available code. This is quite literally the React tutorial starter project. And it became incredibly frustrating, but it also would keep generating things in bursts, so my code is not at all legible or well organized or consistent for that matter. But it’s still better than anything I’d be able to write myself. I’m looking forward to using v0 or something like it to see how that stacks up for some of my ridiculous generation ideas for these things.

Guillermo: Yeah, you touched on a very important point is, the code has to work. The code has to be shippable. I think a lot of AI products have gotten by by giving you an approximation of the result, right? Like, they hallucinate sometimes, they get something wrong. It’s still very helpful because sometimes it’s sending you the right direction.

But for us, the bar is that these things have to produce code that’s useful, and that you can ship, and that you can iterate on. So, going back to that idea of iteration velocity, we call it v0 because we wanted it to be the first version. We still very much believe there is humans in the loop and folks will be iterating a lot on the initial draft that this thing is giving you, but it’s so much better than starting with an empty code editor, [laugh] right? Like, and this applies, by the way to, like, not just new projects, but I always talk about, like, our customers have a few really important landing pages, key pages, maybe it’s the product detail page in e-commerce, maybe it’s your homepage and, like, your key product pages for a marketing website. Maybe it’s where—and the checkout, for example, extremely important.

But then there’s a lot of incremental UIs that you have to add every single day. The banner for [laugh] accepting cookies or not, the consent management dialog. There’s a lot of things that the worst case scenario is that you offload them again to some third-party script, to some iframe of sorts because you really don’t have the bandwidth, time, or resources to build it yourself. And then you sacrifice speed, you sacrifice brand fidelity. And again because we’re the front-end cloud, we’re obsessed with your ability to ship UI that’s native to your product, that is a streamline, that works really well. So, I think AI is going to have a significant effect there where a lot of things where you were sending someone to some other website because you just didn’t have the bandwidth to create that UI, you can now own the experience end to end.

Corey: That is no small thing. A last question I have, before we wind up calling this episode is, there was a period of time—I don’t know if we’re still in it or not—where it felt like every time I got up to get a cup of coffee and came back, there would be three JavaScript frameworks that launched during that interim. So, Next.js was at 1.1 of those when someone got up to get a cup of coffee. But that’s shown a staying power that is, frankly, remarkable. Why? I don’t know enough about the ecosystem to have an opinion on that, but I noticed when things stand out, and Next does.

Guillermo: Yeah, I think it’s a number of factors. Number one, we, as an industry I think, we coalesced, and we found the right engine to build our car. And that engine became React. Most folks building UI today are choosing React or a similar engine, but React has really become the gold standard for a lot of engineers. Now, what ended up happening next is that people realized I want a car. I want the full product. I need to drive. I don’t want to assemble this freaking car every single time I have a new project.

And Next.js filled a very important gap in the world where what you were looking for was not a library; what you were looking for is a framework that has opinions, but those opinions are very in line with how the web is supposed to work. We took a page from, basically, the beginnings of the web. We make a lot of jokes that in many ways, our inspiration was PHP, where server rendering is the default, where it’s very expressive, it’s very easy to reach for data. It just works for a lot of people. Again, that’s the old [stack 00:30:03] in the olden days.

And so, it obviously didn’t quite work, but the inspiration was, can we make something that is a streamline for creating web interfaces at scale? At scale. And to your point, there’s also a sense of, like, maybe it doesn’t make sense anymore to build all this infrastructure from scratch every single time I started a project. So, Next filled in that gap. The other thing we did really well, I think, is that we gave people a universal model for how to use not just the server side, but also the client side strategically.

So, I’ll give you an example. When you go to ChatGPT, a lot of things on the screen are server rendered, but when you start doing interactions as a user, that requires for something like you’d say, “Hey Dali, generate an image.” That stuff requires a lot of optimistic UI. It requires features that are more like what a mobile native application can do. So, we can give folks the best of both worlds: the speed, interactivity, and fluidity of a native app, but we had those, sort of, fundamentals of how a website should work that even Perl and PHP had gotten right, once upon a time. So, I think we found that right blend of utility and flexibility, and folks love it, and I think, yeah, we’re excited to continue to help steward this project as a standard for building on the web.

Corey: I really want to thank you for taking the time to talk about a lot of the genesis of this stuff and how you view it, which I think gives us a pretty decent idea of how you’re going to approach the evolution of what you’ve built. If people want to learn more, where’s the best place for them to find you?

Guillermo: So, head to vercel.com to learn about our platform. You can check out v0.dev, which we’ll be opening broadly to the public soon, if you want to get started with this idea of generative UI. And myself, I’m always tweeting on X, twitter.com or x.com/rauchg to find me.

Corey: One of these days we’ll be able to kick that habit, I hope [laugh].

Guillermo: [laugh]. Yeah.

Corey: Thank you so much for being so generous with your time. I appreciate it.

Guillermo: Thank you.

Corey: Guillermo Rauch, founder and CEO of Vercel, and creator of Next.js. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that will be almost impossible for you to submit because that podcast platform did not pay attention to user experience.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.

Vercel: https://vercel.com/

v0.dev: https://v0.dev

Personal website: https://rauchg.com

Personal twitter: https://twitter.com/rauchg

Transcript

Announcer: Hello, and welcome to Screaming in the Cloud with your host, Chief Cloud Economist at The Duckbill Group, Corey Quinn. This weekly show features conversations with people doing interesting work in the world of cloud, thoughtful commentary on the state of the technical world, and ridiculous titles for which Corey refuses to apologize. This is Screaming in the Cloud.

Corey: Welcome to Screaming in the Cloud. I’m Corey Quinn. I don’t talk a lot about front-end on this show, primarily because I am very bad at front-end, and in long-standing tech tradition, if I’m not good at something, apparently I’m legally obligated to be dismissive of it and not give it any attention. Strangely enough, I spent the last week beating on some front-end projects, and now I’m not just dismissive, I’m angry about it. Here to basically suffer the outpouring of frustration and confusion is Guillermo Rauch, founder and CEO of Vercel, but also the creator of Next.js. Guillermo, thank you for joining me.

Guillermo: Great to be here. Thanks for setting me up with that awesome intro.

Corey: It’s true, if I were talking to someone who looked at what I’ve done, and for some Godforsaken reason, they wanted to follow in my footsteps, well, that path has been closed, so learning a bunch of Perl early on and translating it all to bad bash scripts and the rest, and then maybe picking up Python isn’t really the way that I would advise someone getting started today. The de facto lingua franca of the internet is JavaScript, whether we like it or not, and I would strongly suggest that be someone’s first language despite the fact that I’m bad at it, I don’t understand it, and therefore it makes me angry.

Guillermo: Yeah, it’s so funny because it sounds like my story. And my personal journey was, when I was a kid, I had a—I knew I wanted to hack around with computers, and reverse engineer them, and improve them, and just create my own things, and I had these options for what programming language I could go with. And I tried it all: PHP, Perl, [Mod PHP 00:02:12], [Mod Perl 00:02:13], Apache, LAMP, cgi-bin folders, all the whole nine yards. And regardless of what back-end technology I used, I encountered this striking fact, which was… the thing that can make your product really stand out in a web browser is typically involving JavaScript in some fashion. So, when Google came out with suggestions as you would type in a search box, my young kid Argentinian brain blew up. I was like, “Holy crap, they can suggest, they can read my mind, and they can render suggestions without a full page refresh? What is that magic?”

And then more products like that came out. Google Docs, Gmail Chat, Facebook’s real time newsfeed, all the great things on the internet seemed to have this common point of, there’s this layer of interactivity, real-time data, customization, personalization, and it seems uniquely enabled by the front-end. So, I just went all in. I taught myself how to code, I taught myself—I became a front-end engineering expert, I joined some of the early projects that shaped the ecosystem. Like, there was this library called MooTools, and a lot of folks might not have heard that name. It’s in the annals of JavaScript history.

And later on, you know, what I realized is, what if front-end can actually be the starting point of how you develop the best applications, right, rather than this thing that people, like, reluctantly frown upon, like yourself. I mention that as an opportunity rather than a dis because when you create a great front-end experience, now the data has proven you run a better business, you run a more dynamic business, probably are running an AI-powered business, like, all of the AI products on the planet today are using this technology to stream text in front of your eyes in real time and do all this awesome things. So yeah, I became obsessed with front-end, and I founded this company Vercel, which is a front-end cloud. So, you come here to basically build the best products. Now, you don’t have to build the back-end, so you can use back-ends that are off the shelf, you can connect to your existing back-ends, and we piggyback on the world’s best infrastructure to make this possible, but we offer developers a very streamlined path to create these awesome products on the internet.

Corey: I have to say that I have been impressed when I’ve used Vercel for a number of projects. And what impresses me is less the infrastructure powering it, less the look at how performance it is and all the stuff that most people talk about, but as mentioned, I am not good at front-end or frankly programming at all. And so, many products in this space fall into the very pernicious trap of, “Oh, well, everyone who’s using this is at least this tall on the board of how smart you are to get on the amusement park ride.” So, I feel that when I’m coming at this from a—someone who is not a stranger to computers but is definitely new to this entire ecosystem, everything just made sense in a way that remarkably few products can pull off. I don’t know if you would call that user experience, developer experience, or what the terminology you bias for there is, but it is a transformational difference.

Guillermo: Thank you. I think it’s a combination of things. So, developer experience has definitely always been a focus for me. I was that weird person that obsessed about the CLI parameters of the tool, and the output of the tool, and just like how it feels for the engineer. I did combine that with—and I think this is where Vercel really stands out—I did combine that with a world-class infrastructure bit because what I realized after creating lots and lots of very popular open-source projects—like, one is called Socket.io, and other one called Mongoose—DX, or developer experience, in the absence of an enticing carrot for the business doesn’t work. Maybe it has some short term adoption, maybe it has raving fans on Twitter or X [laugh], but at the end of the day, you have to deliver something that’s tangible to the end-user and to the business.

[unintelligible 00:06:33] Vercel focusing on the front-end has found a magical combination there of I can make the developer lives easier. Being a developer myself, I just tremendously empathize with that, but it can also make more profit for the business. When they make your website faster and render more dynamic data that serve as better recommendations for a product on e-commerce or in a marketing channel, I can help you roll out more experiments, then they make your business better, and I think that’s one of the magical combinations there.

The other thing, frankly, is that we’d started doing fewer things. So, when you come to Vercel, you typically come with a framework that you’ve already chosen. It could be Next.js, it could be View, [unintelligible 00:07:18], there’s 35-plus frameworks. But we basically told the market, you have to use one of these developer tools in order to guide your development.

And what companies were doing before—I mean, this almost seems obvious in retrospect, that we would optimize for her certain patterns and certain tools—but what the market was doing before was rolling out your own frameworks. Like, every company was, basically—React, for example, is a very popular way of building interfaces, and our framework actually is built on top of React. But when I would go to and talk to all these principal engineers that all these companies, they were saying, oh yeah, “We’re creating our own framework. We’re creating our own tools.” And I think that to me now feels almost like a zero interest rate phenomenon. Like, what business do you have in creating frameworks, tools, and bespoke infra when you’re really in the business of creating delightful experiences for your customers?

Corey: What I think is lost on a lot of folks is that if you are trying to learn something new and use a tool, and the developer experience is bad, the takeaway—at least for me and a lot of people that I talk to is not, “Oh, this tool has terrible ergonomics. That’s it’s problem.” Instead, the takeaway is very much, “Oh, I’m dumb because I don’t understand this thing.” And I know intellectually that I am not usually the dumbest person in the world when it comes to a particular tool or technology, but I keep forgetting that on a visceral level. It’s, “I just wish I was smart enough to understand that.”

No, I don’t. I wish it was presented in a way that was more understandable and the documentation was better. When you’re just starting out and building something in your spare time, the infrastructure cost is basically nothing, but your time is the expensive part in it. So, if you have to spend three hours to track down something just because it wasn’t clearly explained, the burden of adopting that tool is challenging. I would argue that one of the reasons that AWS sees some of the success that it does is not necessarily because it’s great so much as because everyone knows how it breaks. That’s important.

I’m not saying their infrastructure isn’t world-class—please, don’t come at me in the comments on this one—but I am saying that we know where its sharp edges are, and that means that we’re more comfortable building with it. But the idea of learning a brand-new cloud with different sharp edges in other areas. That's terrifying. I’d rather stick with the devil I know.

Guillermo: Exactly. I just think that you’re not going to be able to make a difference for customers in 2023 by creating another bespoke cloud that is general purpose, it doesn’t really optimize around anything, and you have to learn all the sharp edges from scratch. I think we saw that with the rise of cloud-native companies like Stripe and Twilio where they were going after these amazingly huge markets like financial infrastructure or communications infrastructure, but the angle was, “Here’s this awesome developer experience.” And that’s what we’re doing with Vercel for the front-end and for building products, right? There has to be an opinionated developer experience that guides you to success.

And I agree with you that there’s really, these days in the developer communities, zero tolerance for sharp edges, and we’ve spent a lot of time in—even documentation, like, it used to be that your startup would make or break it by whether you had great documentation. I think in the age of frameworks, I would even dare say that documentation, of course, is extremely important, but if I can have the tool itself guide you to success, at that point, you’re not even reading documentation. We’re now seeing this with AI and, like, generative AI for code. At Vercel, we’re investing in generative AI for user interfaces. Do you actually need to read documentation at that point? So, I think we’re optimizing for the absolute minimal amount of friction required to be successful with these platforms.

Corey: I think that there’s a truth in that of meeting customers in where they are. Your documentation can be spectacular, but people don’t generally read the encyclopedia for fun either. And the idea of that is that—at least ideally—I should not need to go diving into the documentation, and so many tools get this wrong, where, “Oh, I want to set up a new project,” and it bombards you with 50 questions, and each one of these feels pretty… momentous. Like, what one-way door am I passing through that I don’t realize the consequences of until I’m 12 hours into this thing, and then have to backtrack significantly. I like, personally, things that bias for having a golden path, but also make it easy to both deviate from it, as well as get back onto it. Because there’s more than one way to do it is sort of the old Perl motto. That is true in spades in anything approaching the JavaScript universe.

Guillermo: Yeah. I have a lot of thoughts on that. On the first point, I completely agree that the golden path of the product cannot be documentation-mediated. One of the things that I’ve become obsessive about—and this is an advice that I share with a lot of other startup founders is, when it comes to your landing page, the primary call to action has to be this golden path to success, like, 2, 3, 4 clicks later, I have to have something tangible. That was our inspiration.

And when we made it the primary call to action for Vercel is deploy now. Start now. Get it out now. Ship it now. And the way that you test out the platform is by deploying a template. What do we do is we create a Git repo for you, it sets up the entire CI/CD pipeline, and then at that point, you already have something working, something in the cloud, you spent zero time reading documentation, and you can start iterating.

And even though that might not be the final thing you do in Vercel, I always hear the stories of CTOs that are now deploying Vercel at really large scale, and they always tell me, “I started with your hobby tier, I started with free tier, I deployed a template, I hacked on a product during the weekend.” Now, a lot of our AI examples are very popular in this crowd. And yeah, there’s a golden path that requires zero documentation. Now, you also mentioned that, what about complexity? This is an enterprise-grade platform. What about escape hatches? What about flexibility? And that’s where our platform also shines because we have the entire power of a Turing-complete language, which is JavaScript and TypeScript, to customize every aspect of the platform.

And you have a framework that actually answered a lot of the problems that came with serverless solutions in the past, which is that you couldn’t run any of that on your local machine. The beauty of Vercel and Next.js is we kind of pioneered this concept that we called ‘Framework Defined Infrastructure.’ You start with the framework, the framework has this awesome property that you can install on your computer, it has a dev command—like, it literally runs on your computer—but then when you push it to the cloud, it now defines the infrastructure. It creates all of the resources that are highly optimal.

This creates—basically converts what was a single node system on your computer to a globally distributed system, which is a very complex and difficult engineering challenge, but Vercel completely automates it away. And now for folks that are looking for, like, more advanced solutions, they can now start poking into the outputs of that compilation process and say, “Okay, I can now have an influence or I can reconfigure some aspects of this pipeline.” And of course, if you don’t think about those escape hatches, then the product just ends up being limiting and frustrating, so we had to think really hard about meeting both ends of the spectrum.

Corey: In my own experimentations early on with Chat-Gippity—which is how I insist on pronouncing ChatGPT—a lot of what I found was that it was a lot more productive for me to, instead of asking just the question and getting the answer was, write a Python script to—

Guillermo: Yes.

Corey: Query this API to get me that answer. Because often it would be wrong. Sometimes very convincingly wrong, and I can at least examine it in various ways and make changes to it and iterate forward, whereas when everything is just a black box, that gets very hard to do. The idea of building something that can be iterated on is key.

Guillermo: I love that. The way that Vercel actually first introduced itself to the world was this idea of immutable deployments and immutable infrastructure. And immutable sounds like a horrible word because I want to mutate things, but it was inspired by this idea of functional programming where, like, each iteration to the state, each data change, can be tracked. So, every time you deploy in Vercel, you get this unique URL that represents a point-in-time infrastructure deployment. You can go back in time, you can revert, you can use this as a way of collaborating with other engineers in your team, so you can send these hyperlinks around to your front-end projects.

And it gives you a lot of confidence. Now, you can iterate knowing that before things go out, there’s a lot of scrutiny, there’s a lot of QA, there’s a lot of testing processes that you can kick off against this serverless infrastructure that was created for each deployment. The conclusion for us so far has been that our role in the world is to increase iteration velocity. So, iteration speed is the faster horse of the cloud, right? Like, instead of getting a car, you get a faster horse.

When you say, “Okay, I made the build pipeline 10% faster,” or, “I brought the TLS termination 10% closer to the visitor, and, like, I have more [pops 00:17:10],” things like that. That to me, is the speed. You can do those things, and they’re awesome, but if you don’t have a direction—which is velocity—then you don’t know what you’re building next. You don’t know if your customers are happy. You don’t know if you’re delivering value. So, we built an entire platform that optimizes around, what should you ship next? What is the friction involved in getting your next iteration out? Is launching an experiment on your homepage, for example, is that a costly endeavor? Does it take you weeks? Does it take you months?

One of the initial inspirations for just starting Vercel and making deployments really easy was, how difficult is it for the average company to change in their footer of their website is this copyright 2022? And you have—it's a new year. You have to bump it to copyright 2023. How long do you think it takes that engineer to, A, run the stack locally, so they can actually see the change; deploy it, but deploy to what we call the preview environment, so they can grab that URL and send [it to 00:18:15], Corey, and say, “Corey, does it look good? I updated [laugh] I updated the year in the footer.”

And then you tell me, “Looks good, let’s ship it to production.” Or you tell me, “No, no, no, it’s risky. Let’s divide it into two cohorts: 50% of traffic gets 2022, 50% of traffic gets 2023.” Obviously, this is a joke, but consider the implications of how difficult it is and the average organization to actually do this thing.

[midroll 00:18:41]

Corey: Oh, I find things like that all the time, especially on microservices that I built to handle some of my internal workflows here, and I haven’t touched in two or three years. And okay, now it’s time for me to update them to reflect some minor change. And first, I wind up in the screaming node warnings and I have to update things so that they actually work in a reasonable way. And, on some level, making a one-line change can take half a day. Now, in the real world, when people are working on these apps day-in and day-out, it gets a lot easier to roll those changes in over time, but coming back to something unmaintained, that becomes a project the longer you let it sit.

Part of me wishes that there were easier ways around it, but there are trade-offs in almost any decision you make. If you’re building something from the beginning of, well, I want to be able to automatically update the copyright year, you can even borderline make that something that automatically happens based upon the global time, whereas when you’re trying to retrofit it afterwards, yeah, it becomes a project.

Guillermo: Yeah, and now think, that’s just a simple example of changing a string. That might be difficult for a product engineering in any organization. Or it may be slow, or it may be not as streamlined, or maybe it works really well for the first project that that company created. What about every incremental project thereafter?

So, now I said—let’s stop talking about a string, right? Let’s think about you’re about an e-commerce website where what we hear from our customers on average, like, 10% of revenue flows through the homepage. Now, I have to change a primary component that renders on the hero of the page, and I have to collaborate with every department in the organization. I have to collaborate with the design team, I have to collaborate with marketing, I have to collaborate with the business owners to track the analytics appropriately. So, what is the cost of every incremental experiment that you want to put in production?

The other thing that’s particularly interesting about front-end as it relates to cloud infrastructure is, scaling up front-end is a very difficult thing. What ends up happening is most front-ends are actually static websites. They’re cached at the edge—or they’re literally statically generated—and then they push all of the dynamism to the client side. So, you end up with this spaghetti of script tags on the client, you end up accumulating a lot of tech debt in the [shipping 00:20:56] huge bundles of JavaScript to the client to try to recover some dynamism, to try and run these experiments. So, everyone is in this, kind of, mess of the yes, maybe we can experiment, but we kind of offloaded the rendering work to the client. That in turn makes me—basically, I’m making the website slower for the visitor. I’m making them do the rendering work.

And I’m trying to sell them something. I’m trying to speed up some processes. It’s my responsibility to make it fast. So, what we ended up finding out is that yes, the cloud moved this forward a lot in terms of having these awesome building blocks, these awesome infrastructure primitives, but both in the developer experience, just changing something about your web product and also the end-user experiences, that web product renders really fast, those things really didn’t happen with this first chapter of the cloud. And I think we’re entering a new generation of higher-level clouds like Vercel that are optimizing for these things.

Corey: I think that there’s a historical focus on things that have not happened before. And that was painful and terrible, so we’re not going to be focusing on what’s happening in the future, we’re going to build a process or a framework or something that winds up preventing that thing that hurt us from hurting us again. Now, that’s great in moderation, but at some point—we see this at large companies from time-to-time—where you have so much process that is ossified scar tissue, basically, that it becomes almost impossible to get things done. Because oh, I want to make that—for example, that one-line change to a copyright date, well, here’s the 5000 ways deploys have screwed us before, so we need to have three humans sign off on the one-line change, and a bunch of other stuff before it ever sees the light of day. Now, I’m exaggerating slightly, just as you are, but that feels like it acts as a serious brake on innovation.

On the exact opposite side, where we see massive acceleration has been around the world of generative AI. Yes, it is massively hyped in a bunch of ways. I don’t think it is going to be a defined way that changes the nature of humanity the way that some of these people are going after, but it’s also clearly more than a parlor trick.

Guillermo: I’m kind of in that camp. So, like you, I’ve been writing code for many years. I’m pretty astonished by the AI’s ability to enhance my output. And of course, now I’m not writing code full time, so there is a sense of, okay because I don’t have time, because I’m doing a million things, any minute I have seems like AI has just made it so much more worthwhile and I can squeeze so much more productivity out of it. But one of the areas that I’m really excited about is this idea of generative UI, which is not just autocompleting code in a text editor, but is the idea that you can use natural language to describe an interface and have the AI generate that interface.

So, Vercel created this product called v0—you can check it out at v0.dev—where to me, it’s really astonishing that you can get these incredibly high quality user interfaces, and basically all you have to do is input [laugh] a few English words. I have this personal experience of, I’ve been learning JavaScript and perfecting all my knowledge around it for, like, 20 or so years. I created Next.js.

And Next.js itself powers a lot of these AI products. Like the front-end of ChatGPT is built on Next.js. And I used v0 to create… to basically recreate my blog. Like, I created rauchg.com, I deployed it on Vercel, but every pixel of that UI, I handcrafted.

And as we were working on v0, I said okay, “I’m going to challenge myself to put myself back in the shoes of, like, I’m going to redesign this and I’m going to start over with just human language.” Not only did I arrive to the right look and feel of what I wanted to get, the code that it produced was better than I would have written by hand. Concretely, it was more accessible. So, there were areas of the UI where, like, some icons were rendered where I had not filled in those gaps. I just didn’t know how to do that. The AI did. So, I really believe that AI will transform our lives as [laugh] programmers, at least I think, in many other areas in very profound ways.

Corey: This is very similar to a project that I’ve been embarked on for the last few days where I described the app I wanted into Chat-Gippity and follow the instructions, and first, it round up point—sending me down a rabbit hole of the wrong Framework version that had been deprecated, and whatnot, and then I brought it all into VS Code where Jif-Ub Copilot, it kept switching back and forth between actively helpful, and ooh, the response matches publicly available code, so I’m not going to tell you the answer, despite the fact that feature has never been enabled on my account. So yeah, of course, it matches publicly available code. This is quite literally the React tutorial starter project. And it became incredibly frustrating, but it also would keep generating things in bursts, so my code is not at all legible or well organized or consistent for that matter. But it’s still better than anything I’d be able to write myself. I’m looking forward to using v0 or something like it to see how that stacks up for some of my ridiculous generation ideas for these things.

Guillermo: Yeah, you touched on a very important point is, the code has to work. The code has to be shippable. I think a lot of AI products have gotten by by giving you an approximation of the result, right? Like, they hallucinate sometimes, they get something wrong. It’s still very helpful because sometimes it’s sending you the right direction.

But for us, the bar is that these things have to produce code that’s useful, and that you can ship, and that you can iterate on. So, going back to that idea of iteration velocity, we call it v0 because we wanted it to be the first version. We still very much believe there is humans in the loop and folks will be iterating a lot on the initial draft that this thing is giving you, but it’s so much better than starting with an empty code editor, [laugh] right? Like, and this applies, by the way to, like, not just new projects, but I always talk about, like, our customers have a few really important landing pages, key pages, maybe it’s the product detail page in e-commerce, maybe it’s your homepage and, like, your key product pages for a marketing website. Maybe it’s where—and the checkout, for example, extremely important.

But then there’s a lot of incremental UIs that you have to add every single day. The banner for [laugh] accepting cookies or not, the consent management dialog. There’s a lot of things that the worst case scenario is that you offload them again to some third-party script, to some iframe of sorts because you really don’t have the bandwidth, time, or resources to build it yourself. And then you sacrifice speed, you sacrifice brand fidelity. And again because we’re the front-end cloud, we’re obsessed with your ability to ship UI that’s native to your product, that is a streamline, that works really well. So, I think AI is going to have a significant effect there where a lot of things where you were sending someone to some other website because you just didn’t have the bandwidth to create that UI, you can now own the experience end to end.

Corey: That is no small thing. A last question I have, before we wind up calling this episode is, there was a period of time—I don’t know if we’re still in it or not—where it felt like every time I got up to get a cup of coffee and came back, there would be three JavaScript frameworks that launched during that interim. So, Next.js was at 1.1 of those when someone got up to get a cup of coffee. But that’s shown a staying power that is, frankly, remarkable. Why? I don’t know enough about the ecosystem to have an opinion on that, but I noticed when things stand out, and Next does.

Guillermo: Yeah, I think it’s a number of factors. Number one, we, as an industry I think, we coalesced, and we found the right engine to build our car. And that engine became React. Most folks building UI today are choosing React or a similar engine, but React has really become the gold standard for a lot of engineers. Now, what ended up happening next is that people realized I want a car. I want the full product. I need to drive. I don’t want to assemble this freaking car every single time I have a new project.

And Next.js filled a very important gap in the world where what you were looking for was not a library; what you were looking for is a framework that has opinions, but those opinions are very in line with how the web is supposed to work. We took a page from, basically, the beginnings of the web. We make a lot of jokes that in many ways, our inspiration was PHP, where server rendering is the default, where it’s very expressive, it’s very easy to reach for data. It just works for a lot of people. Again, that’s the old [stack 00:30:03] in the olden days.

And so, it obviously didn’t quite work, but the inspiration was, can we make something that is a streamline for creating web interfaces at scale? At scale. And to your point, there’s also a sense of, like, maybe it doesn’t make sense anymore to build all this infrastructure from scratch every single time I started a project. So, Next filled in that gap. The other thing we did really well, I think, is that we gave people a universal model for how to use not just the server side, but also the client side strategically.

So, I’ll give you an example. When you go to ChatGPT, a lot of things on the screen are server rendered, but when you start doing interactions as a user, that requires for something like you’d say, “Hey Dali, generate an image.” That stuff requires a lot of optimistic UI. It requires features that are more like what a mobile native application can do. So, we can give folks the best of both worlds: the speed, interactivity, and fluidity of a native app, but we had those, sort of, fundamentals of how a website should work that even Perl and PHP had gotten right, once upon a time. So, I think we found that right blend of utility and flexibility, and folks love it, and I think, yeah, we’re excited to continue to help steward this project as a standard for building on the web.

Corey: I really want to thank you for taking the time to talk about a lot of the genesis of this stuff and how you view it, which I think gives us a pretty decent idea of how you’re going to approach the evolution of what you’ve built. If people want to learn more, where’s the best place for them to find you?

Guillermo: So, head to vercel.com to learn about our platform. You can check out v0.dev, which we’ll be opening broadly to the public soon, if you want to get started with this idea of generative UI. And myself, I’m always tweeting on X, twitter.com or x.com/rauchg to find me.

Corey: One of these days we’ll be able to kick that habit, I hope [laugh].

Guillermo: [laugh]. Yeah.

Corey: Thank you so much for being so generous with your time. I appreciate it.

Guillermo: Thank you.

Corey: Guillermo Rauch, founder and CEO of Vercel, and creator of Next.js. I’m Cloud Economist Corey Quinn, and this is Screaming in the Cloud. If you’ve enjoyed this podcast, please leave a five-star review on your podcast platform of choice, whereas if you’ve hated this podcast, please leave a five-star review on your podcast platform of choice, along with an angry, insulting comment that will be almost impossible for you to submit because that podcast platform did not pay attention to user experience.

Corey: If your AWS bill keeps rising and your blood pressure is doing the same, then you need The Duckbill Group. We help companies fix their AWS bill by making it smaller and less horrifying. The Duckbill Group works for you, not AWS. We tailor recommendations to your business, and we get to the point. Visit duckbillgroup.com to get started.