Vercel Migrations, AI & Ship with Dom Sipowicz

(01:24) Thanks. Things that you are proud of or you would like to share with us—like how come you finally became a solutions architect at Vercel? Yeah, because I don’t have grey hair, you know, so I’m not a fully fledged architect yet. However, I do have quite a lot of experience under my belt. I joined Vercel more than three and a half years ago. I joined as an engineer but I pivoted to the professional services team—which we’ll probably touch on later on. I specialize in Next.js, e‑commerce, web performance and a little bit of SEO, and for the last few years Gen AI as well, and I’ve worked mainly with enterprise customers. If my question will be what’s the most unusual or different thing about working for Vercel—is there something like this, is there any magical power at this work for you? That’s an interesting question. More? Most difficult? Well … I think Vercel is moving really fast as a company. We’ve got many products and a lot is happening. (02:43) We’re shipping fast. Recently we had Vercel Ship—we’re probably going to also talk about it. The hard part is the high bar, high level of all the engineers at Vercel. So for me personally when I joined I had this impostor syndrome: Vercel hiring from the industry a lot of celebrities from the development world and, you know, and then they hired Dom—who is coming from Kraków, Poland—and that was like a clash of things for me in the beginning, but after three and a half years I think I’m doing okay. So taking the whole experience you mentioned—I think there’s a question that’s very common in, like, the world of for instance X communities or just project maintainers that aim to achieve some open‑source audience goal: what is, in your opinion, the biggest difference between enterprise clients and medium‑sized businesses? That’s a really good question. (03:51) So you touched on X and social media. The most visible presence in my opinion is that you’ve got devrels, you’ve got pushing new products, new open‑source projects, and this is what’s super visible from the outside about Vercel because we do those things, and it’s great for all developers. We very deeply care about the DX—developer experience. (04:17) However my team—so I’ve got a lot of experience and actually mainly what I do day to day is I’m working with enterprise customers, like you said—and the difference is very subtle. Because if you think about some templates or examples or ways of working—ways of deploying CI/CD pipelines—if you put hobby and pro or indie hackers here and enterprise here, those are two different worlds. (04:52) So I operate mainly in this enterprise part, and this has been my main experience for the last three and a half years. I can talk about that. Yeah. In terms of examples, if you think about deploying, Vercel is the best platform for indie hackers and everything is super simple and designed for the best DX. (05:12) However, the enterprises have their own workflows—their own ways of working—like different release cycles: indie hackers just push to main, right? Yeah. YOLO coding or vibe coding these days, right? And enterprises have different CI/CD. I worked for example before joining Vercel; I had one CI/CD pipeline with 18 steps. (05:39) You know, indie hackers or smaller projects—you just merge and you have maybe three checks, something like that. Maybe you have those unit tests, end‑to‑end tests or blocking releases. It’s totally different—different worlds. Basically it’s like a collision of two worlds: the indie developers that actually prefer to experiment, move fast and not have actual structures of work or processes that need to be done before, for instance, deploying; and on the other side there’s the enterprise world where most things must be structured and most things are enormous. But as you mentioned—like the CI/CD with 18 steps—this is something that must be handled in a reliable way. There are more differences I can talk about. For example, enterprises work in sprints, agile. You’ve got those boards, Jira, you get this end of sprints—you know—show and tell demos. Indie hackers follow releasing at the moment of finishing a feature—you just release it. By default the Vercel platform follows trunk‑based development; that’s the default workflow when you onboard on Vercel. However, I would say around 90% of enterprises follow Git flow, so they’ve got multiple environments—QA, pre‑prod, staging—and the same is reflected in their branching strategy, which is a QA branch, etc. At the end of the sprint they have this merge party where they merge everything and then create a release. It’s totally different in enterprise and in smaller projects or this indie world. Also you have a different approach to security because indie hackers start to get interested in security when they’re under attack or when the usage is higher on the platform. That’s the moment when you pay more attention to best practices or security. This is, to be honest, something that we deal with in my team. I can talk about my team, by the way, as well—how this looks at Vercel. (07:32) I’m going to give another example: Vercel is super big on open source and we have a lot of open‑source content on the internet. We share it, we contribute, we sponsor it and we have examples of different templates. There is actually a template catalog on Vercel where you can choose different kinds of templates you want to kick‑start your project from—or migration. (08:25) When you’re an indie hacker, you can just take this template, deploy it with one button to Vercel and start building on top of that. (08:45) Enterprises—well, it’s a whole migration process. It’s a proof of concept, usually. Then there’s a talk about MVPs, and sometimes even those templates aren’t enterprise ready. This, by the way, is actually something I want to put out to the internet. In my personal opinion it’s really bad that we have just one template for something—for a solution. It should be something that is enterprise grade and a normal solution to a problem. And we are talking about headless CMS, maybe enterprise e‑commerce. A follow‑up question to what you said—let’s move to your team. (09:16) But I wonder—how do you see your role typically in the migration process or when you pick up a new cooperation with a new client? What’s your role? What are the steps if there are typical steps? Because you mentioned that every process is slightly different. (09:36) There are definitely some common areas in your work when you’re onboarding a new client or starting to work with a new client. So what will be your flow—your approach—to onboarding a new client or starting a new cooperation? (10:06) Okay. So first of all my team only works with enterprise customers—and usually the biggest brands at Vercel—and when we onboard new enterprise customers for professional services, because this is what my team is doing, some of the stuff is standard: discovery phase, questions—what needs to be done, what’s the level of maturity the development team has. Sometimes customers work with agencies, software houses or have in‑house development, so there’s a different cooperation if the agency is our official Vercel partner, which I know that Blaz is. So there are custom different approaches to that. But I would say first you want to do some kind of assessment, then identify the gaps—whether it’s knowledge gaps in the dev team, whether it’s technology gaps, maybe it’s architecture gaps. And here you mentioned migrations, so I would say that much more than half of our projects that we work with are migrations. And here’s the funny part: my team can be engaged in, like, halfway through—that migration already started—or my team can engage from the very beginning phase. In this discovery phase the business is ‘okay, we have a budget’, ‘okay, we’re planning what to do.’ If my team is going to be engaged at the very beginning of this process we found that actually the success is more likely because we can have input on the architecture, on the technology stack, on best practice. (11:29) This is from day one. Migration starts with P, which is proof of concept. Then you’ve got this MVP when you start dropping some production traffic, and then you’ve got this production‑grade rollout, which is already, you know, with 100 per cent of traffic. Let’s say the earlier you start engaging with professional services the better it is before you’re going to start writing code or making these technology decisions. For example, this is tremendously important and impactful for e‑commerce migrations. (12:16) If we identify that there are some development gaps—like somebody is using a different agency that is an Angular shop and not, like, Blaz or Next.js experts—you want workshops and training. This is something we do in our team. If it’s a midway migration we can create an audit of the code, web‑performance audit, usage audit, and across this engagement we can provide consultation hours, architecture review and best practices. So that’s roughly the process of onboarding. (13:10) I’m asking specifically about the migration because it’s one of the, as you said, common cases that many clients—I would say at least from my experience both enterprise level and startup/scale‑up level—are looking for something better, something different than they have. (13:35) So in your opinion what’s really—like, what’s the motivation, what’s the sentiment behind this decision for the enterprise‑grade clients? This is very interesting for us because some of us have had the privilege or chance to work with enterprise clients—or some of us just want to do this at some point in the life cycle of the company or our personal growth. So why are those companies coming to Vercel—to you guys, to your team—and what are they looking for? (13:54) Funny what you said about having the privilege to work with enterprise customers. Well, I only work with enterprise customers. So I would like to, you know, work with small startups as well at some point. Vercel—in that’s my personal opinion—at some point became a synonym of fast web. This is, by the way, our core mission of Vercel: our leadership is focused and experienced with the web, and we want to make the web the fastest. That’s our core mission of our company. All across—from top to bottom—we have expertise to deliver exactly that in the enterprise world through use cases, through success stories. We’ve proven that deploying to Vercel using Vercel’s ecosystem, which is open‑source—Next.js, other frameworks—you have bigger chances for success because of the great defaults. Deploying to Vercel: a lot of default things are happening behind the scenes that make your deployment just fast. I’m talking about ISR and other stuff—we can talk about it, dig deeper into the tech. However, those companies and businesses heard about it, they know about it, and they choose Next.js with Vercel and naturally become enterprise customers and then at some point have this professional services engagement. So that’s the motivation for sure. (15:17) So faster processes, faster deployment—generally faster experience for the users. That used to be the case since the beginning; literally that’s a bedrock and the foundation. However, you know, for many years it’s not only faster but also secure. So we have the Vercel firewall and all security certificates are on our platform. And there’s actually more to security than people usually understand. This is a great example of the difference between indie hackers/hobby/pro and enterprise. We now talk about security, for example. So we’ve got web performance, security and AI native. In my personal opinion there’s no better platform right now to start AI workflows—AI applications—AI native. And there’s a reason for that. If we’re going to have time to cover those topics, I can say more about that. So the social proof—blog posts, those use cases and those logos of the customers that deploy and use Vercel—is super important. When you see those logos and they perform, they have great conversions. We have use cases where, in e‑commerce for example, when you have those migrations and suddenly those businesses quote numbers like ‘oh, 30 per cent conversion lift, better visibility, Core Web Vitals are much greener,’ and on the end of the day that hits the bottom line. And for the business people the bottom line is probably the most important, especially in e‑commerce. (17:19) The security thing—I think that—and also the AI capabilities—I think those two things, at least in my professional experience working with big pharma for example, or any other highly regulated environment—the security is one of the reasons they decide to move towards some solution or drop some other solution. So I do think that one of the significant factors, decision factors, for any enterprise is how risky it is to use some tool—could actually comment. So I know a lot of projects were won with Next.js and Vercel because of choosing Next.js as this driver platform technology framework. Companies look at how active the project is, how fast the security issues are resolved, what is the disclosure process. With those security incidents I personally believe that Next.js does this really well, and we’re moving fast. If there is any security issue we obviously fix that in the open‑source project, in the framework itself. However, there was a security thing a few months ago; the projects deployed to Vercel were naturally shielded and protected because of our infra—like firewall and all the systems that Vercel provides—which I think is really cool when building for those enterprises that think seriously about security. Also I want to use this opportunity and say that what I’m seeing recently in the enterprise world is that more and more enterprises, because for many years it was like that they wanted to use Vercel for DX, web performance, great tech and features, however sometimes put other CDNs in front of Vercel. If we’re talking about security—that sometimes isn’t fully working concept. So what I’m seeing recently is that those enterprises remove the third‑party other providers—CDN providers—and have only Vercel in front, which is a great experience for all ecosystems, for Vercel and especially for security because if you’ve got some proxy in front of or CDN you lose this fingerprinting. And we’re going to talk about it in relation to Vercel Ship—what was shipped and new features—because there’s really cool stuff that is related to that. (20:18) Yeah, I think if you—I already mentioned that the Vercel Ship—really high level question: what are the most important things from there? Okay. Again I think we should make this distinction between the developers/indie hackers and maybe enterprises. So which one do you want me to answer first? Maybe let’s start with developers as we were talking about enterprises for a while. Because you’re a developer. Yeah, engineer. (21:06) Right. I’ve seen on X the Everything App—what most engineers and web developers are hyped about is Bot ID. That’s basically a thing to replace the CAPTCHA with an invisible CAPTCHA. Tell me—who likes to prove to some UI that I’m not a bot? Nobody. I’m not an NPC, come on—literally nobody. Yeah. Exactly. So Vercel shipped a solution for that and now it’s invisible. See, so this is again this point that you don’t want to put a CDN in front of Vercel because you don’t have this whole flow of fingerprinting, all of this context of the request. You want to use Vercel as a CDN—sorry, as a whole complete infra solution without any providers in front—and then you can use this Bot ID, which is amazing. So this is what developers like. Another thing is actually two things, which is AI Gateway—this is touching on this AI wave of the last two or three years for AI apps and AI development—so AI Gateway, which was announced before but now it’s widely available. We also announced Vercel Fluid Compute. However this time we announced on Vercel Ship CPU‑active pricing—which is another thing, again, something that Vercel is reducing—the prices. So if you think about the last year, all across the board we reduced the image optimisations, ISR, compute—Vercel Fluid actually reduced the function execution time. This is the last swing. The reason why I bundled into those two with AI Gateway is because it’s a perfect setup for AI workloads, AI applications—working with AI models, streaming, etc.—because you don’t pay for the CPU time when it’s idle, when you’re waiting for the AI model to finish. So this is for the developers—those three things. If you’re a developer, this, in my personal view, is the coolest. And if we’re going to talk about the enterprise—oh boy—we have something really big this time for enterprises. And if you’re an enterprise, I think this is the most important three things for you to look into. First, we have Rolling Releases. Have you used it yet? Rolling Release on any project? Nope. No? Okay, so I highly recommend using it because it’s so cool. Rolling Release is like a blue‑green deployment. You’ve got those staging, production and you don’t want big bang, just flip traffic and YOLO what you’re going to do—just look for errors and then maybe roll back. You know, enterprises want this reliability—not only security but actually reliability—being professional, minimising the downtime and stuff. So Rolling Release—picture this simple story now. In the past it was super hard being a release manager. Those companies had, you know, end of the sprint—you’ve got this merge party when poor tech lead, you know, was merging all the PRs—and then releasing. It was like huge, stressful moment and the bucket of PRs … they’re not conflicted for sure because there are tests etc., but the risk is higher definitely, right? You had the whole playbook, runbook, for the whole release process, right? Literally the title in the name is release manager, right? So Vercel obviously strives for the best DX, best practices, and we want to give companies, projects and dev teams the same thing that the big tech companies had with those best solutions—how they work. If you look in the past few years, all those primitives we give—like instant rollback, feature flags, development—everything, this trunk‑based development as a default model and all of that allows you to move faster, more secure, more confidently. So Rolling Release is now—picture this story if you’re a release manager: imagine yourself as, you know, in Star Trek—Captain Picard—holding a coffee, you know, like ‘oh, let’s release it’, engines 5 per cent of traffic, and you’re looking at those errors. DevOps teams—status report of logs. Marketing team—any feedback on socials? And now you’re standing with that and just Rolling Release—5 per cent, 10 per cent, 20 per cent, and you’ve got a dashboard like this command centre, like on Star Trek. You don’t need Mr Spock. ‘Full ahead—50 per cent of traffic’ and then you see errors before and after, difference between the staging and production, and then you see on the right Core Web Vitals—web performance, bedrock, the foundation of Vercel—and then Captain Picard says ‘full throttle—100 per cent of traffic’—thank you, that was my release—no problems, yes, perfect. This concept is, I know, in different projects that we do in Blaz, we used sometimes for the enterprise—we use this concept of canary release, which is very close—canary, blue‑green, A/B—but on the project level, of course. But as you said everything is within the Vercel ecosystem, so of course you can have multiple tools to do that, but you also create more points of failure because you’re using third‑party tools, you’re using Unleash, you’re using all the different tooling around it—which is— And the stack increases and the complexity is even bigger. Yeah. About this complexity—what you said earlier—is that we actually had an open‑source template called blue‑green deployments. But again, it’s cool for, you know, smaller projects. If you’re an enterprise, it’s not finished because you still need to create, you know, sticky sessions, you know, to stick the load‑balanced users or implement Edge Config with Rolling Releases, like this percentage. Right now it’s first‑class citizen on Vercel Platform. It just works—you can start using it. And how cool is that if your job is—if your title is now release management—get this mug, you know? It’s so easy now. Of course. Of course. Yeah. I remember some time ago we were estimating how to implement the Rolling Release in some project just in theory, and we actually were just thinking about making our own implementation—as you mentioned, like, the Edge Config, fetching the content, dividing the traffic. And so now it just works with a couple of clicks in the dashboard. Yeah, that’s amazing. So this is number one thing, I would say, for enterprises. The second thing—oh boy—another big one. I don’t have a great story about this, but it’s about microfrontends. Maybe that’s the reason why I don’t have a good story about it—it’s very opinionated. If you go and you check X, the everything platform app, everyone has a different opinion; everyone’s got different implementations. I don’t want to say too much because we at Vercel obviously are very opinionated. As of today we have first‑class support for microfrontends. So for enterprises, picture your e‑commerce. And it’s so natural when you grow because you’re in this post‑monolith phase, post‑growth cycle, you want to scale. You’ve got this massive traffic. Naturally you have more developers—maybe a few teams—and then your setup, your project, your codebase, your builds, your pipeline, is super complicated. So the best practice actually is to split it. This is where microfrontends come in. For years at Vercel we were advising multisite support. However, you can use microfrontends because it supports both splitting horizontally and vertically—you can do both. That’s the beauty of this approach that we’re rolling out now. For this e‑commerce—what I’m trying to say is that you want to split for, for example, browse journey, which is getting a lot of traffic. You drop advertising—that’s logically different from, let’s say, buy journey, which is, you know, basket, checkout. So you can make it separate applications, separate deployments, separate development teams, separate codebase, separate pipeline—and you can do it. However, the user uses your e‑commerce, buys goods and services and sees only one domain, one e‑commerce shop. And that’s the beauty of it. So what you’re saying is—the maintenance of the microfrontend, let’s say, split project, is way more clear, right? From the DX perspective, yeah, easier to manage all those steps which are—from the end‑user perspective—one funnel, for example. But from the development perspective you’re managing seven different apps or six different apps. I would say not from the business perspective. I would say from development—engineering—there is a super urge and push for splitting because absolutely if you’ve got a monolith, the builds are long, the complexity is long. However, you know, with vibe coding you want this whole context, to be honest. So still you can use a monorepo and then have split. So you still have the AI context of everything but—in my opinion—it was always engineering push. The business would split logically—like I said, browse and buy. So a business could release checkout without affecting the browse application. Or a usual other split in e‑commerce is you’ve got the store‑finder or information pages—CMS‑driven pages—so you can release those which are not mission critical without affecting those stable release funnels—checkout. That could be business requirement. That’s absolutely great, I think, because I can, from the top of my head, also give another angle to this, which is monitoring of each separate service or each separate part of the funnel or any other e‑commerce situation. For example, knowing where something is happening is, for many complex systems which enterprises are using, a challenge sometimes—where is the delay, where is the cold start happening, where are those things actually taking place. And I personally was involved in many processes or projects where we were trying to drill down and we failed. Because it’s so complex in microservice architecture. Yeah. Okay. So that’s why I believe we’re going to nail it down and it’s going to be amazing because of the observability. Exactly. So right now, because we—okay, first of all, we dogfood everything. We’re like client zero and we test everything on ourselves before we give it to customers—enterprise customers. The same for open source, to be honest. So we are running this microservice product for a long time now on Vercel and when you go to analytics, for example, you have split by projects but you can see it from the root. You can say project—the same for observability—and Vercel was also involved in an effort for—you know there’s a standard that all across the stack, when the request goes, you want to trace this request and see all spans from the front end to the back end. Sometimes—well actually—you won’t, and we implement all of that on Vercel Platform—maybe not this perfectly, this back‑end one; however, we do carry over the request IDs and other stuff, so you can implement that. We talked about the first one—Rolling Releases. Second one was microfrontends, both as a first‑class citizen of Vercel Platform. And the third one is a blend of AI agent and security. Because if you’re an enterprise—picture a situation like this. You’re under attack—threat—whether it’s a DDoS or whatever. You’ve got this triggered alert like Vercel anomaly alerts. If you’re an enterprise customer we can set it for you. It’s not a standard thing. And then you click—you go to your Observability tab and/or Firewall tab and you think, okay, yeah, I’ve got this spike. But I don’t know, for example, how to start, how to investigate it. Well, you can just select from left to right that spike and there’s a button, AI agent, Investigate. And then the AI—the AI agent investigates, checks the logs, checks the observability, checks the fingerprints, analyses everything and then identifies what it is with some degree of certainty. And then in the end it recommends you the actions, like, okay, it looks like an ordinary, you know—again, if you’re e‑commerce and maybe your competitors are so jealous that you’re so successful because you’re on Vercel and they don’t know about it—so they’re just attacking you. The AI agent is recommending you, like, ‘do you want me to add this custom rule to Firewall and just isolate your competitors? Let them burn the request.’ And obviously, okay, and that’s the AI agent available to enterprise customers. Nice. Are visual models used for that under the hood? That’s a good question. I presume I would say no, but I don’t know. I don’t know. Okay. Yeah. I thought it’s the kind of question, but … (37:11) Actually going to V Zero—I was also wondering and we are wondering at Blazity—is there a way for V Zero to also help clients—I mean medium businesses or even enterprise businesses—to help with migration? Not only like the area of speeding up the design to code, because we already know that V Zero is excellent in that area. But also, talking about recent public API beta of V Zero, we started to think that maybe V Zero can also be used for other things, like auditing the front end. Oh, okay—interesting question. What do you— That’s a, you know, a small saying—that to automate my work because I didn’t say about my team but we do audits in our team as well. Yeah, that’s a good question. V Zero is used and is designed to be used by everyone. So let that be said straight away. For enterprises I can focus on that and explain it more. We have a customer who used V Zero with the UI—not even with the API. I mean the Open AI‑compatible model in cursor or client or what IDE you’re using. They use only the V Zero UI to migrate a massive 40 applications—so let’s say hundreds of licences of V Zero—for their internal development teams and they managed to, in four or five months, migrate from Angular because they’ve never been Next.js developers. They migrated the massive codebases into Next.js and they did it under a few months. So we have confirmation—and as a professional services I was actually assigned to this project and I worked. The procurement process was huge. So I joined very late to the project and I was surprised that after a few months 80 per cent of the work is already done by V Zero. Seriously. That’s what happened. So, yeah, we have from the field confirmation that it’s possible for those migrations. Then you want to pivot—eject from V Zero—the UI (vzero.dev) to your IDE. You don’t want to VIP‑code everything, especially in the healthcare business—massive company. You eject it and want to use it in your IDE as a replacement for your models that are using today—you know, it’s all about those best practices, best web performance. And so the UI components and everything that V Zero created—this proof of concept. This is what I said about P, MVP, production. Right. So V Zero covered for them this part. However, they didn’t VIP‑code the rest of the part and actually they did VIP‑code it using GitHub Copilot, which they use other models as well, standard, like for Sonar etc. However, what I’m trying to say is that V Zero is truly expert in Next.js. It will avoid putting those client components on one page—it won’t put five useEffects; you don’t want that. You want to avoid that. Or some architecturing the authentication—how you use it skewing more to the client side—you want to avoid all. You want to follow best practice. So to answer your question: yes, we see it a lot. There is tremendous adoption in enterprises in V Zero and I don’t want to spoil anything because I’m not an official Vercel person so I’m not going to tell more. But only one thing—there is a huge adoption in enterprise. Actually we are surprised how big adoption is. Well, me personally I’m surprised how big. Actually regarding V Zero—I was also testing the API myself, but I can say now that at the beginning I was quite sceptical to the model that is excellent and does all the rendering strategies, decisions, composition patterns, the best practice of Next.js—use the context, yeah. I mean, I was really sceptical, but then I just used V Zero—it actually one‑shoted most of the things it was prompted to do or your words—just listed all the things that I wanted it to know from the audit or something like that. You know, I could talk a little bit more about V Zero—or probably I shouldn’t, but it’s public knowledge that we have our proprietary dataset that was used for training. That, I shouldn’t say, influenced the V Zero outputs. That’s public knowledge, and because of that, web performance is by default great and because it’s server components by default great. Security is like foundational—it’s covered. You’re not leaking API keys in client apps, you know. Yes, it happened. Well, not in V Zero, but it is a problem. So when it comes to the AI tools, because we’ve touched on V Zero, what else is something that you are proud of or something that you would like to recommend? You mentioned that Vercel is sort of becoming native for AI development or development backed by AI, and this is super convenient—or becoming super convenient—for the developers as well to use Vercel as a native friendly environment for any AI applications. So what’s under the hood there? Yeah. So on Vercel Ship it was announced—AI Cloud. And, you know, people might think ‘oh, Vercel pivot to AI Cloud’, but it’s a super natural way to do it for us because from the very beginning we were web oriented. Right now AI is web—the interface is web. By the way, Vercel contributed to this streaming UX we have right now with all the chatbots, conversational AI. GPT was created with Next.js. I personally also, back in 2022, you know, December, was hovering around the streaming with Node fetching libraries from OpenAI. We were from the beginning of this AI—gen AI—movement, right? So why AI Cloud? Like I said before, we are our client zero and we are dogfooding our platform. We use Vercel to deploy Vercel. And I’m sure you know because we talked about V Zero: we have AI native product—it’s called V Zero—and it’s deployed and built using open‑source Next.js, which is open‑source AI SDK, and that’s the reason why we created AI SDK—exactly because we started building V Zero. ‘Oh, there’s something missing, there’s a gap’—we created this. ‘Okay, let’s share with the community.’ So we did it the same, like Next.js to Vercel, AI SDK to V Zero. We had a very short feedback loop with our infra team, with our product team, with our frameworks—you know, we are a little bit like Apple. Apple, if you know Apple, how they succeeded is because from the production to sales they were involved or owned the whole process, even the stores, which is not normal for other companies. They had influence on every journey where the users were interacting with the product. So we do the same thing with AI Cloud. You start with your idea—which is the moment of inspiration—you can create a prototype using V Zero, then you deploy it with one button to Vercel. Then you observe it, then you iterate with the Rolling Release, instant rollback—whatever. Then you have V Zero API model to continue development. Then you have Observability. Then you have AI Gateway—you’ve got this marketplace where you have all the models—you don’t need to sign up, give your credit card. You have everything under one API key from Vercel. The billing is through Vercel and it’s the same price. This whole stack we actually use to build V Zero and we are confident, and we’re working with all the providers—other companies like OpenAI, Anthropic, Gemini, xAI. We have all of that journey and that’s why—you know, what is AI Cloud? It’s AI‑native cloud. There—I challenge you—I personally believe there is no better place, platform, to deploy your AI native app, like streaming. You can self‑host this; you sign up to everything. But right now because everyone’s got access to the top key, to VIP‑code—the time is the most important. So we as this AI Cloud give you all of this, you save time. Time is money. Yeah. Yeah. So I hope that answers why it’s AI Cloud. I think it’s perfect. I like it. Of course, time‑to‑market is, I think, nowadays one of the— Iteration velocity. Yeah, absolutely, that’s the most important. But something that we also observe from our, let’s say, field is that there is this misconception of VIP‑coding everything. Like there is this whole myth about you can have your app in ten minutes up and running on the production. Of course you can. It’s possible, right? But what happens next? What happens next? Like, how you maintain this app, what’s the observability, how—from the enterprise perspective especially—how you would know where something is wrong with your app, where exactly it happened? So all those things—and suddenly those ten minutes are becoming maybe weeks. I think you want to use a platform that you know the owners of the platform are engineers first. They contribute back to open source and they dogfood the platform and use the same tools. That was the reason why Vercel was created, because we wanted the best DX. So the same philosophy—speed, security, DX—applies to AI Cloud. I think we can spend probably another three hours talking about different things, but I think we are ready to wrap up. Thank you very much, Dom, for joining us today. It was a real treat to hear about your experience, about your journey, about your team, about the things that are part of this very, very interesting and influential Vercel platform in general. So for me a couple of takeaways from this conversation is that behind very sophisticated tooling there is always an excellent engineering muscle that is sort of taking care of everything that we as developers or companies—we don’t see; this is kind of transparent but it’s always there. To be honest, Vercel tries to be more transparent. But yeah, thank you. It was a pleasure. It was a really good chat. Really enjoyed it. Hope you’re going to invite me more. Thank you very much for joining us today on Next Gen Web Podcast. Thank you for being with us. Remember to follow us on social media, leave a review, follow Dom, follow the community, and thank you again. See you soon. [Music] [Applause] [Music]