v0 is Vercel’s AI tool for generating user interfaces from a prompt, a screenshot, or a Figma frame. What it hands back is real, editable code: React components styled with Tailwind, often built on shadcn/ui, wired into a Next.js project structure. What it does not hand back is a backend, a database, user accounts, file storage, or a production deploy. The interface can look completely finished, buttons, forms, responsive layout, while none of the logic behind it exists yet. Turning a v0-generated interface into an actual product means building the parts v0 was never asked to build, then putting the whole thing somewhere it can run.
The gap between the interface looking finished and the product being finished is where most of these projects stall. Most explanations of v0 cover how to prompt it well and stop there, as if a good screen were the hard part. It usually is not. This post separates what v0 actually generates from what a real product needs on top of it, and walks through the specific list: backend logic, data, authentication, and a place for the whole thing to run.
Table of contents
- What v0 actually generates
- The five things v0 does not build
- Turning the interface into a working app
- Where the generated code needs to run
- A realistic build timeline
- What changes once it is live
- How this fits the rest of the stack
- FAQ
What v0 actually generates
v0 takes a prompt, a screenshot, or an imported Figma frame and returns working React components styled with Tailwind CSS, commonly built on shadcn/ui primitives. It is not a wireframe tool or a picture of an interface. The output is real code: component files, props, state, responsive breakpoints, and dark mode variants if you ask for them.
You can iterate inside the tool, generate several versions of the same screen, refine one with a follow-up prompt, and export or push the result into a Next.js project. For a landing page, a dashboard shell, a settings screen, or a signup form, this compresses what used to be a day of frontend work into an afternoon of prompting.
The quality generally holds up: sensible utility classes, markup that is accessible in most cases, and a file structure a working developer would recognize without translation. That part of “AI built my interface” is genuinely true, and it is also where most write-ups about v0 stop.
The five things v0 does not build
Everything under the interface is still your job. This is not a knock on the tool, it was never asked to do these things, but it is the list that decides whether the result is a demo or a product.
- A backend. Buttons call functions. Forms submit to routes. None of that server-side logic exists until someone writes it, whether as an API route, a server action, or a separate service.
- A database. The generated dashboard shows placeholder rows. Real data needs a schema, a connection string, and a place to live that survives a restart.
- Authentication. A login screen that looks complete has no session handling, no password hashing, and no way to tell one visitor from another yet.
- File and object storage. An upload button with nowhere to send the file is a button. Storage has to be provisioned and wired to the form.
- Third-party integrations. Payments, transactional email, analytics: none of it exists until the provider’s SDK and credentials are added by hand.
None of this is hard in isolation. It is the reason a finished-looking screen and a shippable product are still separated by real engineering work, usually more of it than the screen suggests.
Turning the interface into a working app
The wiring work follows roughly the same order no matter what the app does. Start with the data model: what does one real row actually look like, and where will it live. Then replace the placeholder data inside the generated components with a fetch or a server action hitting a real endpoint.
async function getProjects() {
const res = await fetch(process.env.API_URL + "/projects", {
headers: { Authorization: `Bearer ${process.env.API_KEY}` },
});
if (!res.ok) throw new Error("failed to load projects");
return res.json();
}Authentication comes next, because most of the interesting screens are meant to sit behind a login. Add a session library or a hosted auth provider, gate the routes that need it, and pass the logged-in user down to the components v0 already generated, they usually accept a user prop without much rework.
Last, wire the specific actions the interface implies: a submit button needs a route that validates and stores input, a delete button needs one that checks ownership before deleting anything. This is the bulk of the real engineering time, and it is where the project stops being about prompting and starts being about building.
Where the generated code needs to run
A v0 project that only renders content, a marketing page, a portfolio, a page with no login and no forms, can genuinely ship as a static export. Nothing about that interface requires a server process.
The moment the app has a form that saves something, a login, or data that differs per visitor, it needs a runtime that stays up: something to run the API routes or server actions, hold a connection to a database, and answer requests continuously rather than being generated once at build time and left alone.
This is the same line covered in Does v0 Deploy Just a Static HTML File?: the generator does not decide this for you, the feature set of the screens does. A screen with a working form is not a static page, no matter how finished it looks in the v0 preview.
A realistic build timeline
Founders who expect v0 to compress the whole project the way it compressed the interface are usually disappointed around week two. A more honest sequence looks like this:
- Day 1. Generate and refine the core screens in v0. This part really is fast.
- Days 2-4. Define the data model, stand up a database, and replace placeholder data with real fetches.
- Days 4-6. Add authentication and gate the routes that need it.
- Days 6-8. Wire the actions: forms that submit, buttons that mutate real data, uploads that land somewhere.
- Day 9 onward. Deploy, connect a domain, and start iterating on a live product instead of a preview link.
That is a small team’s timeline for a genuinely useful app, not a toy. It is also roughly the same timeline the same team would have without v0, minus the days it saved on the interface.
What changes once it is live
A live product needs things a preview link never asked for: a custom domain instead of a generated one, logs you can read when a request fails, environment variables that hold real secrets instead of placeholders, and a rollback path for the day a deploy breaks something.
This is also where the maintenance mindset shifts. A v0 preview costs nothing to leave open in a browser tab. A live product with a database and a login has a bill and a failure mode every week, whether or not anyone is looking at it that day.
None of that is a reason to skip shipping. It is the reason the plan for shipping should include a runtime and a database from the start, not as an afterthought once the interface is done.
How this fits the rest of the stack
v0 solves the part of the project that used to eat the most calendar time and leaves the part that decides whether the thing actually works. Once the interface is wired to real data and a login, it needs somewhere to run that stays up between requests: model the service and the database together in the RunxBuild hosting calculator before committing to a plan. Next.js services on RunxBuild cover deploying the kind of project v0 exports, build logs and a live route included, and the dashboard is where the repository gets connected once the wiring is done.
Useful related references:
- Does v0 Deploy Just a Static HTML File? Yes, But That Is the Boring Part of the Question
- Backend Hosting: What a Backend Actually Needs From a Host, and Why Static Hosting Is Not Enough
- No Code Website Builders: Where the Ceiling Is and How to Tell You Hit It
- Next.js services on RunxBuild
FAQ
What is v0 by Vercel used for?
v0 generates working frontend code, React components styled with Tailwind, from a text prompt, a screenshot, or a Figma frame. It is used to build interface screens fast: dashboards, forms, landing pages, and settings panels that would otherwise take a day of manual frontend work.
Can v0 build a full application, or just the interface?
Just the interface. v0 does not generate a backend, database, authentication, or file storage. Those pieces have to be added separately and wired into the components v0 produces before the app does anything beyond looking finished.
Is a v0-generated app ready to deploy as-is?
Only if every screen is static content with no forms, logins, or per-visitor data. The moment a screen saves something or checks who is logged in, it needs a backend and a runtime that stays up, not just a static export.
Does v0 output Next.js code?
Yes, v0 projects are typically structured as Next.js applications with Tailwind and shadcn/ui components, which you can export or push directly into a repository and extend.
What is the fastest way to add a backend to a v0 project?
Add API routes or server actions inside the same Next.js project rather than standing up a separate service first. Connect a managed database, add authentication, and wire the forms and buttons the interface already has to real endpoints.