v0 by Vercel: how prompt-to-UI actually works

When v0 launched in October 2023, the dominant view was that “type a prompt, get a UI” was a parlor trick — fun for landing pages, hopeless for anything real. By mid-2026, 4 million people had used it, v0 was running on a separate $20/month tier, and more than half of v0 revenue was coming from Teams and Enterprise plans. The “trick” became a product line important enough that Vercel’s CEO Guillermo Rauch started openly talking about an IPO, with the company’s ARR up from $100M at the start of 2024 to a $340M run-rate by February 2026.

What changed wasn’t the model. GPT-4 and Claude have always been roughly capable of writing a React component; the problem was that they’d cheerfully write any React component, in any style, with any state management library, on any framework, and never quite produce the same code twice. The result was a thousand demos and zero products you could ship into a real codebase.

v0’s wedge was the opposite of generality. The team made a list of hard constraints — React, TypeScript, Tailwind, shadcn/ui, Next.js — and then built a generation pipeline that refused to deviate from any of them. Inside that box, the model became reliable. Inside that box, the preview loop could render in 200 milliseconds. Inside that box, the code v0 produced could be dropped into an existing Next.js app and just work.

This post is about how the box was built, what’s inside it, and why the competitors chasing the same market have all converged on narrower-and-narrower variations of the same idea.

The pipeline

A v0 generation is a streaming, four-stage process. The user submits a prompt — usually one or two sentences — and watches a preview pane materialise the UI as code is generated. From the Vercel docs and Rauch’s own descriptions, the stages are:

Parse intent. A frontier reasoning model (Vercel uses a mix of OpenAI and Anthropic models behind the scenes, with their own fine-tuned routing) reads the prompt and extracts a structured description: what page type, what major sections, what data shape, what visual tone.
Plan component tree. The model picks shadcn/ui primitives that map to the request. A dashboard prompt becomes <Sidebar> + <Card> + <DataTable> + <LineChart>. A landing page becomes <Hero> + <FeatureGrid> + <TestimonialCarousel>. The set of primitives is finite and well-known; the model is essentially choosing from a menu.
Stream code. TypeScript and JSX stream into the preview sandbox character-by-character. Tailwind classes are resolved as they arrive. The preview iframe re-renders as the code lands.
AutoFix pass. A separate streaming post-processor (Vercel describes this in their maximizing-outputs guide) scans the output for type errors, missing imports, unused variables, accessibility violations, and a list of common shadcn anti-patterns, and rewrites them in place.

v0’s four-stage generation. The streaming preview is the load-bearing UX trick — the user is no longer waiting for a finished output, they’re watching it appear.

The stage that took the longest to get right, by Vercel’s own accounting, is the AutoFix pass. The base models will produce JSX that looks correct but doesn’t compile under strict TypeScript, or that uses shadcn components incorrectly (passing a deprecated prop, forgetting the forwardRef, mixing controlled and uncontrolled state). AutoFix is a separate fine-tuned model that catches a finite list of these mistakes and rewrites them, before the preview re-renders. It’s the boring layer between the magic and the user.

Why shadcn/ui is the architectural choice that mattered

The single most important design decision in v0 isn’t in the model stack. It’s the choice to standardise on shadcn/ui, a component library that — and this is the unusual part — is not a dependency. shadcn/ui is a set of copy-paste React components, owned by your repo, built on top of Radix primitives.

This matters for v0 in three ways.

It’s a finite, well-typed vocabulary. When the planner stage picks components, it’s picking from roughly 80 primitives that the model has seen thousands of times in training data and that have stable, typed APIs. This collapses the space of “what does a good React component look like” from infinite to enumerable. The model isn’t reasoning about JSX from scratch; it’s composing from a Lego kit.

The generated code drops into the user’s codebase as files they own. Because shadcn isn’t a library, v0’s output isn’t dependent on some Vercel-internal package — it’s plain TypeScript files that import plain shadcn primitives that the user can edit. This is why v0 output ships. Compare with a hypothetical generator that produces components depending on @vercel/v0-components — the moment the user wants to customise something, they’re forking your library.

The styling is constrained too. Tailwind classes are a finite vocabulary; design tokens (bg-primary, text-muted-foreground) are defined by the shadcn theme. The model can’t invent novel CSS, which sounds limiting but is precisely the discipline that makes the output coherent. Two different prompts produce visually consistent UI because the styling surface is locked.

This is the lesson the GPT-wrapper era missed. People kept trying to build “generate any UI from any prompt,” with the model emitting raw HTML/CSS or styled-components or Material-UI or whatever the model chose to use that day. The result was outputs that worked individually and looked nothing like each other. v0’s strategy is the opposite — narrow the surface until the model’s output is consistent, then make that consistency a feature.

The preview loop

The other half of v0’s UX is the streaming preview. When you submit a prompt, the right pane in the v0 UI is a sandboxed Next.js iframe that renders the generated code as it arrives. The interactive feel is the killer feature, but the engineering underneath is non-trivial.

The preview runs on Vercel’s edge runtime, with a per-session sandbox that’s spun up in tens of milliseconds and discarded when the generation completes. Each code chunk is HMR-applied to the running preview, so the user sees the layout assemble, the styles resolve, and the typography settle as the LLM streams tokens. By the time the model finishes writing, the preview is already on the final state. There is no “now compiling” step between generation and display.

This is the part that made v0 feel like a different product class. The GPT-wrapper version of “build me a dashboard” gives you a wall of code that you copy into your editor, paste, hit save, and hope. v0’s version gives you a working dashboard you can click on while it’s still being written. The user’s iteration loop is instant — see something wrong, say what to change, watch it change.

The iteration is also conversational. v0 isn’t a one-shot generator; follow-up prompts can ask for narrow changes (“make the sidebar collapsible”, “use a darker primary colour”, “add a search box”), and the model knows what state the component tree is in. The conversation is what makes v0 feel like a collaborator rather than a code generator.

The competitive landscape

By 2026, several products have followed the v0 template into adjacent markets. The interesting thing is how their architectural choices diverged.

Four products, four positions on the scope-versus-quality trade-off. v0 won by going narrowest; the others picked broader scopes and accepted the quality hit.

Bolt.new (from StackBlitz) widened the scope to full-stack generation by running an entire WebContainer-based dev environment in the browser. The bet is that “build me a full app” is a bigger market than “build me a UI.” The trade-off shows up in code quality — Bolt-generated full-stack apps work, but the code is messier and harder to drop into an existing codebase.

Lovable widened it further, targeting non-developers who want a working product. The interaction model is closer to a conversation with a project manager — describe the product, see the result, iterate on the design. The audience overlap with v0 is small; the overlap with Replit Agent is larger.

Tempo went the other direction, narrowing in on the design-to-code handoff. It’s effectively a Figma replacement that ships React, aimed at design teams that want to compress the design-to-engineering loop.

The thing all four share is the opinionated stack. None of them lets the model emit arbitrary HTML. Every successful product in this space constrained the output to a single component library, a single framework, a single styling system. The teams that didn’t constrain either didn’t ship or shipped products that nobody used twice.

What v0 doesn’t do, and probably won’t

It’s worth being clear about v0’s limits. The 2026 product is excellent at:

Generating individual UI components and small page compositions.
Iterating conversationally on visual and structural design.
Producing code that drops cleanly into an existing Next.js + shadcn app.

It is mediocre at:

Anything with non-trivial application state. v0 can produce a form; it doesn’t know how to wire it to your auth system or your backend’s data model in a meaningful way.
Anything outside the Next.js + shadcn lane. Want a Vue.js component? Want plain HTML/CSS? Want Tailwind 2 (not 4)? You’re not in the audience.
Long, multi-screen flows where the agent needs to maintain state about what’s been built across many turns. This is where Bolt and Lovable have advantages.

Vercel’s strategic answer to those limits has been not to address them. The v0 docs are explicit: v0 is a UI generator. The full-app generation lane is left to others. The bet is that being the best at one thing beats being mediocre at three, and the revenue numbers support it.

What to take away

Narrow the surface to widen the audience. v0 is a master class in the counter-intuitive truth that constraining the generation space increased the user base, because the output became reliable enough to ship.
Streaming previews change the product class. The instant visual feedback loop is what made v0 feel like a creative tool rather than a code generator. Any prompt-to-X product where X has a visual representation owes itself a streaming preview.
Pick a component library that’s owned by the user. shadcn/ui’s copy-paste model — where the generated code’s dependencies are files in your own repo, not packages in node_modules — is the underrated piece of v0’s design. It’s what makes the output portable.
An AutoFix pass beats a smarter model. The narrow, well-defined error classes inside the v0 constraint can be fixed by a small specialised model in a follow-up pass, much cheaper than upgrading the base model to never make the error in the first place.

The instinct in early codegen was to chase generality — generate any UI, in any framework, with any style. v0’s success says the opposite. The durable products in this category are the ones that picked a lane and went deep. The bet that “Next.js + shadcn” was a big enough lane was non-obvious in 2023; in 2026, with a million weekly active users on v0 and a $340M-ARR parent company, it looks like the bet of the cycle.

Further reading: Vercel’s maximizing-outputs post is the closest thing to an architectural overview the team has published. The v0 docs on design systems describe the shadcn constraint at the level of detail useful for a builder. Guillermo Rauch’s Acquired interview covers the strategic framing. For comparison, UI Bakery’s v0-vs-Bolt-vs-Lovable breakdown is the most useful third-party head-to-head.