I spent a week generating 35 UI components with v0 by Vercel to understand where it fits in a real development workflow. The tool occupies a narrow but valuable niche: it does not write backend logic, manage state, or replace a frontend engineer. What it does — generating React components with Tailwind CSS and shadcn/ui from natural language prompts — it does well enough to change how I approach the early stages of UI work. Here is what 35 generations taught me about where v0 shines and where the output still needs a human to finish the job.
The Generation Pipeline Is Fast Enough to Change Behavior
The speed of v0's generation is what makes it useful in a way that slower AI tools are not. When I typed "a pricing page with three tiers, a monthly versus annual billing toggle, and a testimonial section at the bottom," v0 produced a rendered React component in a browser preview within 8 seconds. I refined it through four follow-up prompts — "highlight the middle tier as recommended," "add an enterprise contact link below the tiers," "reduce the vertical spacing between the testimonial cards" — and had something presentation-ready in under three minutes.
This speed matters because it changes the cost-benefit calculation for visual exploration. Before v0, if I wanted to compare two layout options for a dashboard, I would sketch both on paper or in Figma, pick one, and implement it. With v0, I generated both options as rendered components in under 30 seconds each, compared them side by side, and picked the better one after seeing it in an actual browser rather than a mockup. I did this seven times across different component types — dashboards, settings pages, landing pages, modal dialogs — and the visual comparison consistently revealed issues I would not have caught in a static mockup.
The iteration loop is the most underappreciated part of the experience. Unlike code generators that produce one output and leave you with the result, v0 maintains context across iterations. When I asked it to "add a search bar to the top of the dashboard," then "move the search bar to the sidebar," then "add keyboard shortcut hints next to each search result," it remembered the search bar placement, the result formatting, and the overall layout from each previous step. I counted 11 iterations on a single dashboard component before the context started to degrade — after that point, the model began forgetting earlier layout decisions and reintroducing elements I had asked it to remove.
In my testing, v0 consistently produced a rendered UI component under 15 seconds for first-generation prompts and under 10 seconds for iterative refinements. This fast iteration loop is what separates v0 from general-purpose code generators. You are not waiting for code and then rendering it yourself — you see the result immediately and refine it conversationally. I found this workflow useful enough that I now start most UI components in v0 before moving to my editor, even when I know I will rewrite significant portions of the output.
What the Code Actually Looks Like
This is where I need to be specific about what v0 produces, because the marketing screenshots show polished components but do not show the code behind them, and the code matters for anything beyond a static demo.
I generated a settings page with a sidebar navigation, a main content area with form fields, and a save button. The output was 340 lines of JSX — correct, functional, and visually matching what I described. But when I reviewed the code, I found that the same flexbox layout pattern was duplicated across three sections, the button styling was repeated on six different buttons with identical classes, and a color palette was defined inline in four separate places instead of using a CSS variable or Tailwind theme extension.
I refactored the generated code and reduced it to 180 lines by extracting a shared layout component, a shared button component, and a centralized color configuration. The 160-line reduction was not surprising — this is how AI-generated code looks across every code generator I have tested. But it means the time v0 saves on initial generation is partially offset by the refactoring time you need to invest before the component is ready for a production codebase.
The shadcn/ui integration is the strongest technical decision in v0's design. Because shadcn/ui components are copied into your project source rather than imported as a dependency, v0 can generate code that uses them without requiring a specific version or installation step. In my testing, v0 correctly imported Button, Dialog, DropdownMenu, Input, and Label from the project-relative shadcn path in every generation where those components were needed. It verifies the import paths against the actual components.json configuration, which is how it knows to use @/components/ui/button rather than @shadcn/ui/button or any other path your project might not have configured.
The Tailwind usage is correct but verbose. Every generated component uses utility classes correctly — no invalid class names, no contradictory utilities, no missing responsive breakpoints. But the classes are applied individually to every element rather than extracted into reusable patterns. A card component with 12 Tailwind classes on the outer div and 8 on the inner content div is correct but would be cleaner as a single component with internal class management. v0 optimizes for visual correctness, not code cleanliness, and that choice shows in the output.
Where the Output Stops Being Useful
v0 generates presentation-layer components only. This is the single most important limitation to understand before you invest time in the tool. When I generated a login form with email, password, and submit button, the output looked complete — styled inputs, a submit button with hover states, even error-message slots with proper styling. But there was no form validation, no loading state management, no error boundary, no connection to an authentication endpoint, and no state management for the form fields beyond the default HTML input behavior.
I had to add 85 lines of React code — useState for form values and errors, useEffect for validation on field change, an async submit handler with try-catch, and a loading state that disabled the button during submission — to make the generated 120-line component actually functional. The markup-to-logic ratio was heavily skewed toward markup, which is exactly what v0 promises. But if you look at the total time to production-ready code, the generation saved roughly 40 minutes of writing JSX and styling, and I spent roughly 35 minutes adding interactivity and state management. The net savings were 5 minutes on a one-hour component — not nothing, but not the transformative speedup the demo makes it look like.
Multi-page coherence is where v0 consistently fails. I generated a dashboard with a sidebar, a table view, and a header in one session. Then I generated a settings page in a separate session. The sidebar navigation did not match between the two — the dashboard sidebar had three navigation items, the settings sidebar had four, and the highlighting logic used different class patterns. The color scheme was close but not identical — the dashboard used a gray-800 background and the settings page used a gray-900 background, which is a one-shade difference that a human would notice but an AI session with no cross-generation memory would not.
If you are building a multi-page application with v0, you need to treat each generation as an independent starting point and manually reconcile the inconsistencies. I solved this by creating a shared layout component outside v0, generating individual page content through v0, and then dropping the generated content into my pre-built layout shell. That workflow gives you the speed of v0's generation without the inconsistency of independent sessions. It also means v0 cannot be the sole UI development tool for anything beyond a single-page prototype.
The Ecosystem Lock-In Is a Real Consideration
v0 generates React components with Tailwind CSS and shadcn/ui. There is no Vue output, no Svelte output, no Solid output, no plain HTML and CSS output. If your project uses any frontend framework other than React, v0 is not relevant to your workflow. I tested this by asking v0 to "generate a Vue component" and it produced a React component with a comment saying it could be adapted to Vue. The tool genuinely cannot target non-React frameworks.
Within the React ecosystem, the dependency on shadcn/ui means v0 works best when your project already uses that component library. You can use the generated code without shadcn/ui — the output uses standard HTML elements where possible and only imports shadcn components for interactive elements like buttons, dialogs, and dropdowns — but the experience is designed around Vercel's stack. If you use Material UI, Ant Design, or a custom component library, you will spend time replacing shadcn imports with your own equivalents.
The Vercel deployment integration is a genuine convenience if you are already on Vercel. A generated component can go from prompt to a live preview URL in roughly 45 seconds, which is useful for sharing prototypes with stakeholders who cannot run code locally. But the integration is not neutral — v0 encourages you toward Vercel's deployment, Vercel's component library, and Vercel's frontend framework. The tool is free during its current phase, but the ecosystem lock-in suggests a pricing model is coming that will be harder to walk away from if v0 becomes a core part of your workflow.
When v0 Replaces My Manual Work and When It Does Not
After 35 generations across a week of UI development, I reached a clear conclusion about where v0 fits. For rapid prototyping where visual fidelity matters more than code quality — a founder preparing a pitch deck, a product manager exploring layout options, a designer communicating intent to engineering — I would use v0 before I would open Figma or write markup manually. The browser-rendered output communicates more than a static mockup, and the iteration speed makes it practical to explore three or four visual directions in the time it takes to wireframe one.
For generating the initial markup of a component that I will then wire up with state, validation, and data fetching, v0 saves a real and measurable amount of time — roughly 30 to 45 minutes per component in my testing, with the understanding that I will spend 25 to 35 minutes of that adding interactivity. The net savings of 5 to 10 minutes per component do not sound dramatic, but across a project with 15 to 20 components, that adds up to two to three hours saved on boilerplate markup.
For production-ready UI development where code quality, reusability, and consistency matter more than generation speed, v0 is a starting point, not a finishing point. The code needs refactoring to extract shared patterns, the state management needs to be added manually, and the multi-page inconsistencies need to be resolved outside the tool. v0 saves the time between "I have a visual idea" and "I have something rendering in the browser." The time from "something rendering" to "production-ready component" is still yours.
I have not found a scenario where v0 replaces the judgment of an experienced frontend developer. It is a tool for accelerating the gap between design intent and initial implementation — a gap that is real and time-consuming — not for eliminating the implementation work entirely. The components it generates are the best-looking AI-generated UI I have seen, but they are still AI-generated UI, with all the verbosity, inconsistency, and incompleteness that category implies. Use v0 for what it is: a fast, visual starting point that gets you to the interesting part of the work faster.
Originally published at pickuma.com. Subscribe to the RSS or follow @pickuma.bsky.social for new reviews.