LongCut logo

A conversation with Vercel's Guillermo Rauch

By Stripe

Summary

Topics Covered

  • Self-Taught Coding Bootstrapped Global Success
  • Dominate Niche Before Unbounded Ambition
  • Agents Replace Pages in AI Internet
  • Progressive Disclosure of Complexity Wins
  • Design DX for LLMs Not Humans

Full Transcript

Well, thanks so much for being here today for Build Day.

Build Day's really all about turning great ideas into great products, and so when we stepped back and asked what that might mean, we thought, well, no better company to talk to than Vercel, who's very much at the forefront of making that possible, and Guillermo, in particular, who, of course, is the genius behind Next.js and Vercel in parallel.

So, lots of good conversation to be had around open source- Good to be here, thank you. -And business.

I think earlier this year you guys announced 200 million ARR and a doubling of users year over year.

For those of you who are reasoning about sort of scale and what might be possible, I heard 4.3 million downloads a week of your AI SDK alone.

Yeah, it's hard to keep count of downloads 'cause they're growing so fast.

Good problem to have.

But, yeah, the business has been growing really fast, and, as many others I think here, it was born in the cloud and it was born on Stripe.

Amazing, and, you know, I think with many of today's startups, rather than reasoning about year-over-year growth, we're increasingly reasoning about month-over-month growth or even week-over-week growth- Day.

Day. Day?

You could ship something today that makes a huge difference.

Always elevating ambitions, amazing.

Well, thank you for being here.

I thought we could start maybe a bit with your background.

Born in Buenos Aires, taught yourself how to code?

True story?

That's right, yeah.

Curious about kind of your early journey and what brought you to the US.

You know, there are a lot of parallels between what I set out to do with Vercel in my early days because teaching myself to code and speak English was quite the challenge, but- You taught yourself English?

English was not spoken at home?

The funny story, no.

In fact, my parents were really interested in it 'cause, in Argentina, like, the country was always divided between like capitalism and socialism.

And my parents were very much like engineers themselves, industrial and chemical engineers, and they had a lot of admiration for great engineering.

And they knew that the cutting edge would be in Silicon Valley in the United States, but you needed to know English in order to get there.

And so I was interested in software engineering, and I noticed that a lot of the programming manuals, documentation, readmes, were in English.

So I basically had a bootstrapping process to do.

And I tell people these days that, you know, AI is sort of a before and after because, if I go back in time and I'm trying to teach myself how to code, I can do it in my native language, and I can do it at every step.

I can just ask the LLM to teach me.

Like, literally, one of the things with LLMs is like, "Explain quantum mechanics like I'm five."

I could have done that.

I could have- When you were five.

You could have done that when you were five, yeah.

So I didn't have that.

The next best thing was the internet, and the next, next best thing was open source.

So, for me, one of the discontinuities in my learning journey was when I started getting to know the open-source communities, contributing to open source, spending a lot of time connected with strangers on the internet, as one does, and learning together.

And so I started contributing to a lot of web frameworks.

One of the earliest was called MooTools.

It was a JavaScript library, and that was actually very formative.

You know, if I think of my resume, my resume was a bunch of the open-source projects that I contributed to.

And the web itself was for me sort of the vehicle that allowed me to basically leave Argentina and become a worldwide figure in programming because the instant that I was able to use the web to very quickly ship things, fork something and put it out into URL, now you have a worldwide audience, right?

These hyperlinks can travel at the speed of, you know, thought pretty much.

So fast-forward to Vercel and had the same inspiration.

If you wanna start a company, if you wanna start a digital business, if you wanna ship your next big idea, I need to make it extremely easy.

I need to remove all of the friction.

And, funny enough when I was here in Silicon Valley, I had already sold my first business to WordPress, I noticed that, you know, the cloud was all the rage.

I always encourage people to think about platform shifts very closely.

Clearly now we have a platform shift towards AI.

Like 10 years ago when I started Vercel, the platform shift was towards the cloud.

I looked at the cloud, and it was so hard, even though I had like 10 years of engineering experience under my belt.

And so Vercel set out to remove all friction, from idea to global cloud application.

And so you're kind of developing Next.js and Vercel, one open source, one is a business, in parallel.

I'm curious like hard trade-offs along the way when you had to make a call, one versus the other.

Yeah, where there was no trade-offs was in my vision.

I wanna make the web easy, and so when I was thinking about it from first principles, something that you guys love to do here at Stripe, okay, I sat down, and I needed two halves of this equation.

I needed the tooling, compilers, programming language, runtime framework, and then I needed the cloud infrastructure.

And so interestingly enough, I noticed an asymmetry in the market.

I noticed an unmet need because most of the platform providers were leaving the framework side for you to figure out.

So AWS and Google Cloud and whatever, like, here's a bunch of like virtual machines and clusters and networking solutions.

Right, you do the rest.

It's like the meme of draw the rest of the owl.

They were like, "Here's some primitives.

You figure it out how to build an application."

And so I looked at it from first principles.

I was like, "Wow, that's strange," 'cause as I'm in the act of drawing this proverbial owl, I'm realizing I need tooling.

And so that's where the idea of Next.js came from.

It's like, hey, I wanna create an application that is of the sophistication, performance, and flexibility of the giants of the internet 'cause I always caveat my little storytelling with, look, there were ways to publish to the internet really easily.

You could have, you know, go to Squarespace or Wix or Tumblr.

Like, there were ways to get something online, but my aspiration was that you would be born- much like Stripe-like, your business is born on Vercel.

It never graduates because we give you infinite scale and infinite power.

And so I solved the Next.js side, made it open source, and then I also needed to solve the other equation with half of the equation, which is, all right, how do you host and scale this?

And I also set a really high bar for myself.

I wanted to make it universally performant.

I wanted to make it such that without even being an expert in optimization or infrastructure, you could deploy something that scales and performs excellently.

And so those were the two things.

One is more on the business side, and the other one is sort of our presentation to the world.

Our cover letter to the world is start with Next.js or any other open-source frameworks that we contribute to.

I mean, awesome that they were so hyper-complementary, right additive.

Were there hard trade-offs you made?

I mean, even in your own time- Yes.

Like where you spent your own time and energy?

Yeah, it's funny because I had to overcome a few bad, I guess, intuitions in order to get there.

One intuition that I had at the beginning is: in order to create the world's best and most successful startup, I have to make everybody happy, like every single person.

I feel like that's just a life lesson.

In order to be the best, yeah, you don't have to make everyone happy.

You have to be somewhat disagreeable.

Yeah, so who did you agree to disagree with?

So interesting and this is why like the story like seems so simple now that I tell it, it's like, "Oh, wow, like, genius.

Of course, you created the framework and the infrastructure."

In the beginning, the infrastructure was so generic that I was trying to appeal to everybody.

You liked Java.

It's like, "Oh, I can't let Emily down.

I'll do some Java over here.

Oh, and you like Next?

Oh, okay, I'll do some Next.

Oh, and you..."

And so I really was just beginning to straddle myself like really thin.

And so the principle that I've now extracted from this that I'm very happy to share with the world, because it can save you some pain, is your ambition for a venture-backed business that'll reach global scale should be pretty much unbounded.

Like, we're here today.

We're gonna colonize Mars someday, sometime in the future.

So that's the like long-term aspiration and ambition.

But you also have to meet it with realism because, if you're just pure unmitigated ambition, you're gonna be so up in the clouds- not the actual cloud, but the, like, metaphorical cloud- that you're not gonna get anything done.

You might get into a situation being jack of all trades, master of none-extremely dangerous situation to be in.

You might get into the situation of what some call it like, you know, having a million mediocre customers versus 1,000 customers that really love you.

And so what was obvious in retrospect, and we did end up doing is, "Hey, we'll start by dominating a niche."

So the niche was- which is funny because I think a lot of things that we believe are niches turn out not to be- 'cause we've had $250 million of revenue from a niche, which is front end.

First chapter of Vercel was front end, hosting the front-end side of websites and web applications, and then CDN and security services.

Our next step, which has come way later than I would've expected, is back-end: agents and the AI cloud, and all those things.

In many ways, you have to earn the privilege to expand that product lineup or that customer base in order to get to the ultimate ambition of your business.

Actually, we're seeing that in a lot of the companies that are being built now.

What feels like a niche with like a global user base- and especially sort of like ability to reach markets that are well beyond our own-are not niches at all.

They're like very, very large markets.

Okay, but you had to make hard trade-offs at the start.

100%. Had to shoot for the stars and then decide like which planet you were gonna land on first. 100%.

on first. 100%.

You talked about like, you know, the new frontier is AI, and we've talked a bunch about open source versus closed source.

I'm curious in the context of AI how you think about open-source models versus proprietary models, both in terms of like what the industry is building, but also in terms of like how developers should adopt the two.

One of the things that I believe is that once your business reaches product market fit, you can't get too satisfied, right?

Because the world will expect you to do more.

Your customers will want you to do more.

You'll have the people and funding to do more.

So you can, you know, expand into other adjacencies.

And one of the rules for when do I expand into my next chapter- there's a bunch of rules that I have or principles.

One is what I call brand permission, meaning if Vercel tomorrow launched a washer and dryer product, even if it's slick and black and beautiful, you'd be like, "That's a little strange.

I was expecting them to launch maybe like an AI coding tool."

Like your brand doesn't yet give you permission to launch a washer-dryer.

And also you want to expand into adjacencies to your core competence.

So, if you do payments, you can handle billing next.

Or, if you do payments, you can handle fraud next and things like that.

And so, for us, with our new chapter of becoming the AI cloud, what we realized is that there is a lot of demand for the same things that we did in the past.

People want simple frameworks, tools, and solutions for creating agents.

There's like a new protagonist in this story.

I call it, first chapter of the internet was about pages or pixels.

In fact, if you've used Next.js, you know that the very first thing we asked you to do was create a pages directory and toss your files in there.

It's like very much PHP-inspired.

The next chapter- Pages and pixels replaced by?

Agents.

And so agents might not even have a face, so to speak, intelligence that is sort of permeating everything you do, meeting you in every conversation, in every platform integrated into Slack, integrated into Zoom, integrated into, you know, parsing your documents while you're doing other work.

And so this is a completely different paradigm of the type of software that we've all been building.

And this is why it's exciting to start a business today because that feels to me like a platform shift, and what's interesting about platform shifts is that the old thing doesn't disappear.

So it's not that tomorrow there'll be no pixels or we'll get to a point where there is no pixels.

Much like today, we still have AM and FM radio, so the older technology is still there, and it'll have- I think in the case of the web, pages and URLs and links are gonna continue to have a ton of relevance.

But clearly there's a new type of software people wanna build, and there's a new opportunity then to provide the infrastructure and framework.

So just like there was Next.js, we created the AI SDK.

You called out it has 4.2 million downloads a week.

I think it's actually gonna surpass Next.js.

Next.js now feels old compared to like this new hotness.

It's like my new love interest.

No, but they're complementary.

There's like a foundations cloud, and there's an AI cloud that you can build on top.

And so whenever you have an idea for an agent or an assistant, you will naturally gravitate towards a platform that speaks your language, and that's what we're building now.

Yeah, so you guys are really at the forefront of helping developers build with AI.

We partnered with you to make Stripe sandboxes native inside Vercel.

And I'm curious sort of how you thought about integrating payments within your stack and why it felt sort of worthwhile to you.

Yeah, maybe for some context, my original ambition transcended Next or Vercel or the cloud.

It was, okay, if I have a great idea, how can I convert it into a productive software entity or business or whatever?

And so my tool or my inclination was, look, JavaScript, I mentioned when I was a kid, I worked really hard to learn English, but I also worked really hard to learn JavaScript.

And what I really liked about JavaScript was it felt like the English of the programming universe.

Of course, there's lots of languages.

Spanish is not too bad, but English, if you just learn English, think about how much you can accomplish.

It's awesome.

Same with JavaScript.

So JavaScript can run on the server side, client side, edge, build time.

It can be used to provision infrastructure.

And now our bet is it's gonna be the main language of orchestrating AI services, making API calls to models, creating agents and workflows, et cetera.

So that was the inclination, is like, "enable the world, broadly."

Now, a little bit of a detour has been, well, kind of like ironically, perhaps, English is becoming the next hot programming language.

So we created this tool v0 where it feels like a self-disruption.

JavaScript allowed us to enable tens of millions of people to create, but that's still a very small number.

How many people can express ideas?

So I'll give you actually an actual proxy that I use.

Slack and Teams have approximately combined half a billion monthly active users.

What do those people do when they open Slack?

They, generally speaking, talk about building software or building some kind of business, and they go back and forth.

"Hey, Emily, how much money did we make yesterday?"

And she's like, "Well, what do you mean by money?

Like, tell me exactly what MRR metric you want."

It's like, "Okay, see you tomorrow."

But we go back and forth in some conversation around building a business.

Imagine if we could take those words and actually more directly and concretely build software.

That was the original idea of v0.

And so for us, it means that we can take that pool of people that are in the creator sort of category from like 20 million to 500 million.

And so we recently integrated Stripe because obviously what you learn when people start building software is that they wanna monetize it.

So we made an integration such that every person that puts a prompt into v0 or creates an application into Vercel has a seamless integration with Stripe where you don't even need to set up the environment.

You just get this sandbox provisioned.

And it even surprised me, but it quickly became our third-most popular integration in the entire platform.

It should not be surprising because anytime you build something, you need that flywheel of: is this actually working, and do people want it?

And the best thing you can do is sell that thing and get feedback from the market.

So it's been amazing because I think, jointly, we're enabling not just the people that know how to code or are proficient in coding, but now the next generation of, whether you call them vibe coders or not, but it goes back to that original mission of enabling everyone to ship.

Any sort of surprising businesses that you've seen spin up with sandboxes like that you didn't expect, you know, just from going through?

Well, there's a lot of people that are building, like, ideas.

They might have a main job, and then they're like building sort of their, like, startup, their dreams on the side.

I feel like I've seen an amplification of this, where, you know, for me, when I was at my previous company, I was dreaming of the company I was gonna create next.

But I think the barrier- But you weren't building it yet.

The barrier felt too high.

It was too hard.

That's right. That's right.

And so I think there are a lot of people now that, you know, one thing that's been really surprising is younger people.

So obviously, I had this story-my personal story-of like, I had to learn quite a bit in order to actually become someone that could sell something online, just integrating all the services, programming languages, et cetera.

I've been hearing from people that are professional engineers that tell me, "Look, my siblings, they're like 12, 13 years old, and they're already selling products online."

So that's also been really surprising.

The other one that's even more surprising, perhaps, is within enterprises, the same sort of inclinations are in play where people have ideas, but they don't have the resources to execute.

And so giving them a tool that can enable fast prototyping...

One that was maybe not related to payments specifically but was bewildering to me is we heard about a company that went from v0 to patent filed just through like prototyping, trying it out, going back and forth with customers, visualizing the idea, et cetera.

Like, okay, this actually is a meaningful evolution of our business.

Without a tool that allowed them to move this fast, they need to like get engineering resources.

They need to do all these things.

So there might be a renaissance of, you know, it seemed like the only way that a enterprise scale could innovate is by acquiring a startup or by some people leaving and starting a startup where like they were free to innovate and use tools and move really fast.

I think there's a version of this that's gonna happen within existing companies, and it's been exciting to play a role there.

I can't get out of my head this vision of like a five-year-old Guillermo, doesn't speak English yet, in Buenos Aires, sitting at a v0, you know, computer.

What would you build?

So it's happening already, right?

So one thing I've been struck by is people send us like the really cool things they build with v0.

They share the chats in our community, et cetera.

And it's been amazing to see that a lot of these chats are not in English.

Japanese Spanish Arabic like, the LLMs just don't care.

Is it as performant in non-English?

So this is the other thing that's been shocking.

So I've only had limited exposure, so I haven't done a rigorous analysis, but from my vibe-ometer, Spanish is amazing.

So that young Guillermo maybe would not speak English today 'cause he continued- Wouldn't have needed to, yeah.

building in Spanish.

But the other thing that's fascinating is this is not a one-way door, right?

A lot of people are starting with v0 and they're becoming proficient engineers later.

A lot of people ask me like, "Do you believe that this tool replaces the engineering role?"

I don't think so, and I already have enough evidence from seeing people telling me, like, "I spent three months in v0.

It opened my mind to the different kinds of special skills that it could develop later.

And now I do this, and I connect to Git, and I use other tools.

And I'm going towards that journey of proficiency."

I don't think people should necessarily stop at prompting.

In fact, this is how I quote, unquote, "code" today.

Whenever I have an idea, it's actually way more practical for me to put it into v0 and send a prototype to my team than try to express the same idea either in Slack or text messages or whatever.

Or, you know, sometimes the friction to coding and creating an environment, it's just too high.

And so I think these tools will continue to coexist in order to help people dream up really big things.

Okay, so your own developer experience- Vercel's obviously known for an incredible developer experience.

AI is changing what it means to be a developer.

What do you think good developer experience is gonna look like a year out, two years out, three years out?

Yeah, one thing that's definitely changed in how we operate internally is that we talk of the LLM as our customer.

So it used to be that I designed Next.js only for people, and the persona that I would imagine in my head is, all right, there's this developer.

Maybe they've had some exposure to PHP.

Maybe they know some HTML.

How can I relate to them?

In fact, and I haven't shared this too broadly, but the very first version of Next.js looked a lot like a templating language 'cause I really badly wanted to merge the world of React, which seemed a little divorced from the mainstream of programming at the time, and I wanted to make it super relatable.

I wanted to make it like MySpace codes.

I wanted to make it like, "Oh, it just looks like HTML with some JavaScript logic on top."

Or even Shopify Liquid looks a little bit like this.

And so my customer was that developer.

And, whenever I design something, I try to think of a very broad range of skillset.

This has been sort of like a personal mantra that I have.

I call it progressive disclosure of complexity, which is actually something that's really hard to do.

How many years old is Stripe?

I mean, it depends when you count from but like slightly over a decade.

Okay, so in ten years, a company will add more and more complexity commensurate to the customers that come in and the deals that they make.

So, if Stripe is supporting Shopify, the needs of Shopify are way more advanced than the needs of a one-person shop.

So, how do you maintain the simplicity of the early days, when it was mostly used by one-person shops, ten years in?

And so my personal rule is, one, it's possible.

It requires a ton of work, but the rule is progressive disclosure of complexity or sophistication, meaning you still should present yourself where you meet the needs and complexity and experience of that customer that comes in through the door.

And then over time, if needed, you reveal your more complex self.

And so I think there's a version of that happening now where, in order for me to make a product that is good for one person or a one-person team or we now host two of the top 20 websites on the internet by traffic, I need to be very, very cognizant of how do I expose the complexity to the end user.

But, again, that end user is no longer just a human.

We think of the agent and how is the agent gonna reason through this.

Little example from literally last night.

One of our framework builders that works on what do we call agentic developer experience, he said, "Look, what happens when agents use Next.js is that they will boot up lots of dead servers and kill them and boot up lots of dead servers and kill them."

And this is not a behavior that a human does.

A human boots up one.

They go to work to their tech center, that's it.

And, in some ways, agents are better because they try lots of things really quickly, and if you give them rope, they'll do a lot of stuff in parallel.

And so what we realized is that in one error message in Next.js, we had to include the process ID in order to give agent context of what process to kill in order to recover the port that the previous process was using.

This tiny amount of information- hashtag and then identifier of the process- is enough to boost the developer experience, not for people, maybe actually marginally for people 'cause like what I would do if I was an engineer is like, oh, I would run PS and then grab my Next and then find the process and whatever.

Like, not a huge difference for people can make a gigantic difference for agents.

And so, as developer tools continue to advance, they will continue to cater to this LLM that calls tools and commands rather than people.

The people will still be behind the agent instructing it.

The other metaphor that I use is that, you know, instead of thinking of yourself as a junior engineer that joins a company, you're basically like a junior engineering manager that joins a company, and what you're managing is a fleet of agents.

I like successively revealing complexity.

I'm wondering if that works in personal life as well.

Yeah, I meet you and we start talking about something basic, shared, and then we can end up talking about like colonizing Mars.

Yeah yeah yeah.

Let's talk about business models.

Business models in the AI era are different, unique complex.

I'm curious how you've thought about Vercel's own monetization strategy, business model, and kind of what you're seeing in the market with all the businesses being built on v0.

Yeah, when you engineer platforms, some of the early decisions that you make can be highly regrettable in the future.

One of them is how you structure.

I think a lot of people that have built products might relate to this, for example, how you structure users, teams, organizations, workspaces, roles, et cetera.

You make some decisions, and then you wake up five years later, and you're like, "Oh, I wish I'd done it differently."

And I think there's a version of this with pricing models.

So if young, five-year-old Guillermo in Argentina was asking me today like, "What advice do you have for like how I should structure my pricing?" I would say- I feel like that's a question you might have asked.

Yeah totally especially because I would be chatting with the LLM, and the LLM would be like, "Yeah, you have to think about this."

But so, for a couple rules of thumb.

So one is optimizing for high-iteration velocity, not just of your product, but your pricing and packaging and the way you bill.

Like, it's gonna undergo constant change.

Another one is optimizing for transparency.

One of the big weapons that Vercel has today relative to old incumbents is that you can buy anything off the shelf, and then we transparently tell you how much it costs down to a very specific unit, request, data transfer unit, token of AI.

And the world has very much evolved to this way of buying, where you have a session with an agent like v0, and then we tell you like, this part of the conversation literally costs you this many credits because you used up this much of intelligence.

So, we very much live in a world where everything is on tap.

Intelligence is on tap and power.

I think of cloud computing as power.

I almost think of what Vercel does as a utility.

You want us to scale to infinite concurrency.

So, for example, we host all of the prediction markets.

We host Polymarket, Kalshi, and a bunch of the crypto ones.

Today they're probably having a massive day.

Why? Because everyone's hitting refresh on the New York election.

I'll probably do it when I leave this room.

Hey, I could see you're antsy.

You wanna know what's happening.

And so Vercel is basically letting you draw as much power as you need.

And we do it in a way that they didn't need to call 'em and say, "Hey, there's an election coming up.

Can you just give me a little bit more power, bro?"

No, it's like on demand, and that means that we need to optimize for a system of enormous transparency, real-time accounting.

So you can go to Vercel and-at any time, in real time-see, all right, how many requests, how many compute microseconds.

Same for the build process.

So, if you have 100 engineers or one engineer, we can provision one build unit or 100 build units.

Your team grows.

You can draw more compute.

The same is happening with tokens, right?

There's some engineers at your company that will be having very long sessions with the agents.

There's some that are gonna be more parallel.

There's some people that, you know, frankly, as much as I am agent-pilled, I have some engineers working in some frontier domains where AI gives them no returns today, people working on very advanced compiler or cloud infrastructure that there's just not enough data or whatever.

And so you need this very fluid model of accounting, billing, et cetera.

And so what I would be thinking today when you think about your pricing model and how you monetize is- especially if there is an intelligence component or a power component- how do you do some of that real-time transparency back to your customer?

But also, the SaaS models are still very relevant.

There's a lot that is rightfully metered by seat or by project or by some other kind of unit.

So, where Vercel exists today is kind of a hybrid world of this very much on demand and also for some things that are more related to collaboration, other aspects of building software, more traditional like you would pay for GitHub or Figma or others.

And, of course, Stripe has evolved to meet this level of complexity. Yeah, we do.

of complexity. Yeah, we do.

We see a lot of this hybrid billing model, right?

You want the sweet, sweet ARR, but you also don't wanna charge the same amount to the person who's using, you know, in browser base like a couple hours a month as the person who's using thousands of hours a month.

And, I'll tell you, sometimes entrepreneurs can get into a little bit of a cold-start problem because if you do everything on demand, then you might have 100,000 customers that pay you like 3 cents a month.

And you have fixed platform costs.

You have platform costs because you had to like get something up and running in order to just be online and serve your user base.

And that's why I'm actually, number one, I'm a fan of extreme experimentation.

I think no one really knows the answer to these hard problems, and so you have to get out there and try many things.

But the other one is that I think I'm quite open-minded about like more of the hybrid ways, and obviously it's great that, you know, you have a lot of the infrastructure already built.

So doing it for yourself I do not recommend.

It's quite hard.

I wanna jump back to something you said earlier about like the web today is built on pages.

Pages aren't going anywhere, but there's kind of a new dominant interface that's popping up.

We didn't really talk about...

We talked a little bit about what that's gonna demand from the infrastructure layer.

We didn't really talk about what that's gonna demand in terms of new protocols, and I'm curious sort of what's top of mind for you.

Yeah, one thing I mentioned briefly is if the programming language of tomorrow is human, that means that you'll likely be integrated into a lot of the places where the conversations are already happening.

So, if you and I are chatting on WhatsApp, then we might create a group with a bot that is there in WhatsApp, or if we're in Slack, same thing.

So, the interface that has been the poster child of this first era of AI is conversation, in talking to these agents, in prompting, and I expect that to continue.

What's also true is that a lot of these platforms already exist.

So there's already ChatGPT.

There's already Grok.

There is already v0.

There's already Cursor.

And so paying attention to the protocols that allow you to meet customers where they are.

Literally, this morning I was getting a really nice- I was telling you about it- pitch about a data AI company.

And the founder's making the case that one of the key interfaces for his product is gonna be the MCP server because a lot of companies are building their own AI interfaces.

I meet a lot of enterprises that have basically their own internal ChatGPTs.

We have one at Vercel.

You guys have one.

Shopify has one.

And so your product might not have a pixel interface, per se.

You might just come to the company and say, "Hey, Stripe, if you connect to our MCP server over here, you're gonna get this value from us."

So, I'm paying a lot of attention to MCP.

We have a lot of customers in e-comm.

Black Friday is gonna be a huge day for us, also for Stripe, of course.

And a lot of the questions that I get are, "How do I survive and thrive in an age of agentic browsers?"

Meaning, you know, the customers tells it like, "Get me this beautiful black sweater."

It's a beautiful black sweater.

Do you think agent commerce is overrated or underrated?

I thought you were gonna ask me, "Where do you get it?"

No, I don't need one, but it looks- I don't think agent commerce is overrated because I think, at least for myself, I always get the same things, the same black shirts 200 times a year, and so there is a kind of purchase that you make that is very predictable.

Again, context is king, always has been, even more so now within in the age of AI.

That little example that I gave you of like we improved the Next.js error message by five characters, and all of a sudden, like, the world works way better- the same is true for how you bring context.

That's just a way of doing context engineering.

The concept that we put into the agent determines the quality of the outcome.

For commerce, I think if you have really good context in like what my preferences are and my history of purchases, there's a lot that you can automate.

I expect it to play a role even in the world of pixels because what a lot of merchants- the dragon that they've been chasing and have never quite gotten to- is that you open favoriteshop.com, and it knows exactly what you want instead of a generic static page.

This is literally why Vercel like...

A lot of our business, why it's so successful, is we helped people not ship static pages and dynamically render and personalize.

But I think a lot of these pages and interfaces are gonna be LLM-backed.

So, imagine behind the scenes of producing a page, there's an LLM with a lot of context.

And imagine that the tool calls that it can make is the orchestration of your UI components.

So, all of a sudden when I go to, you know, keith.com, the LLM is producing the page.

That's the mental model that I have.

Now, some people are gonna go to keith.com.

Some people are gonna go to chatgpt.com.

And so you need both.

You need the protocol to integrate it into big chat, and you also need to, yourself as a business but also the way that you should think about it, is empowering the businesses that also wanna maintain their own interfaces with the customer.

And with this new customer that's the LLM, both at the same time?

Yeah, the customer might be an LLM.

The customer might be a traditional user.

The way that I think about it is when I go to the airport, and I walk past my favorite store, I might still be inclined to have a human-centric experience.

So I walk in and I explore, and ideally I would want that to be hyper-personalized and tailored to me.

Another interface will be the agent browser, meaning I tell it like, "Get me my black sweater again," and it just goes off and gets it.

And then the other interface will just be purely the agent that you're not directly interfacing with but some other agent.

So this is kind of the agent-to-agent model.

There's an e-commerce agent over here, but I'm interfacing with some other agent that in order to fulfill its purpose, it needs to buy something.

We did a little demo.

I mean, this sounds like science fiction, but we did a little demo of this with Stripe, where imagine that you're coding, and you're talking to a coding agent, and you tell it, "Deploy."

And the agent-you haven't made a deployment decision yet- the agent says, "Well, in order to deploy it, I'm gonna use Vercel 'cause it's the best."

How does that agent successfully procure a Vercel account and pay for it, so that what it gives you is actually the outcome that you wanted?

You wanted a live URL or you wanted a deployment, and it just fulfilled the commercial transaction as an implementation detail.

Obviously, you will want oversight.

You want your payment methods to be, you know, persisted.

You want fraud prevention.

You want all the good things of buying, but think of it as like my assistant is doing the purchase.

I mean, there's disproportionate talk of agentic commerce in the B2C context, but I think the B2B is far under-discussed, and procurement could look very different a year from now.

Amazing, that is all we have time for today, and a huge thank you to Guillermo for the insights shared.

I know I'm walking away with a lot and hope you all are too. - Thank you all.

Loading...

Loading video analysis...