From v0 to a real site

What do you have after v0, and what is still missing?

You have source code for interface parts: a button, a form, a whole screen. That is the layer your visitor sees, and the layer in which you most quickly have something that looks finished. That is also where the confusion lies: a screen that looks finished feels like a product, while it does not yet save a single action of a visitor.

What is missing is not the design but the frame around it. A project that holds the parts together and that can be built. Addresses, so every page has its own URL. Real data, because the sample data in a component will have to come from somewhere. A receiver for your forms, because a submit button that goes nowhere is a drawing of a submit button. And the things that have nothing to do with appearance: hosting, domain, database, secrets, backups.

The good news: that is a list, and a list you can work through. Nothing on it is hard. Everything on it is invisible as long as nobody tells you.

• What you have: source code for screens and components, in the conventions of the framework they were made for.
• What still has to happen: a project around it, an address per page, real data, a receiver for forms.
• What stands apart from the appearance: hosting, domain, database, secrets, backups.
• What you do not have to do: everything at once. For each step, choose the smallest version that is good enough.

How do you get your components out of v0 and into your own project?

A component is ordinary source code, and source code you take with you. In practice there are two routes: you fetch the code of a part and paste it into a project you manage yourself, or you let the code land in a code repository your project draws from. Which routes v0 offers today and how you start them, you look up in the v0 documentation under export and version control. Take that as your source, not a blog post from half a year ago.

More important than the route is the receiving side. Make sure you first have an empty, working project that you can build. Then check four things per component. Does the project run on the same framework and the same major version? Does it use the same styling convention? Are the dependencies the component asks for installed? And are the import paths correct? A component that asks for an icon set or a component library that is not there will stop your project from building. That is one of the few error messages on this route that you get right away, and so a gift.

Then work screen by screen and build in between, so you always know which step broke something. Keep track of what you took over and what you adjusted yourself, because as soon as you continue working in the tool, two versions of the same screen exist.

• Look up in the v0 documentation which export routes exist and follow those above any general explanation.
• Start with an empty project that demonstrably builds, and only then paste into it.
• Check framework, version, styling convention and dependencies before you paste.
• Take over one screen at a time and build in between.
• Keep track of what you changed yourself, or you will overwrite it in the next round.

Where do you host your project and how do you link your domain?

A project with components is usually not a folder of ready-made files but something that first has to be built. So you are looking for a host that builds and deploys your code, not just a place that serves files. v0 belongs to Vercel, so hosting with Vercel is close at hand. That is a fact about distance and not a recommendation: any host that can build and run your framework is an equally good candidate, and you compare them on the same four requirements.

Those four: can you link your own domain, do you get automatic HTTPS, can you set environment variables without putting them in your code, and can you leave without rebuilding everything. The last one is forgotten most often and counts the most. A host that treats your code as ordinary code is a host you can leave.

The domain itself is a one-time job. You buy the name from a registrar and set up two kinds of records: an A record that ties your bare name to an address and a CNAME for a subdomain such as www. Your host usually tells you exactly what needs to be there, and that instruction takes precedence over any general explanation. Expect minutes to hours before a change is visible everywhere, choose one form as the real one and redirect the other to it, and turn on HTTPS before you share the link.

• Choose a host that builds and deploys, not one that only serves files.
• Four requirements: your own domain, automatic HTTPS, environment variables, and a way out.
• A record for the bare name, CNAME for www, and your host's instruction takes precedence.
• One canonical form, redirect the other; wait for the TTL before you conclude that it is broken.
• Prices and free tiers change quickly, so they are not in this guide: check the official v0 pricing page and that of the host you choose.

Hosting and domain are covered in more detail in the main guide: which hosting to choose and how to link a domain.

What do you do with your database and your secrets?

An interface has no memory. As soon as a visitor saves something you need a database, and as soon as your project talks to another service you have keys. These are the two topics that stay untouched the longest because you do not see them, and both are small jobs as long as you do them in time.

For the database, a managed relational database is the safe default choice: someone else does the updates and the backups, and the format does not belong to one provider, so you can leave. Turn that backup on and restore from it once for real, because a backup you have never restored is an assumption. Keep your schema in migrations so you can see what changed when. And store only what you use: every field you do not keep cannot leak.

Secrets belong in environment variables at your host, never in the code. Locally you use a .env that stays out of version control, with a .env.example next to it that contains only the names. In a project with a front end, pay extra attention to the difference between keys the browser may see and keys that exist only on the server. Most frameworks use a prefix in the name to mark which variables go along to the browser. Look up in your framework's documentation which prefix that is, and assume that anything the browser can fetch is public. If a key has ever leaked, you rotate it, because removing it from the code does not revoke the old value.

• Managed relational database, backup on, and one real restore test.
• Schema in migrations, and store only what you really use.
• Secrets in environment variables at the host; .env out of version control.
• Look up the prefix for public variables in your framework's documentation.
• A leaked key you rotate; removing it is not enough.

In more detail in the main guide: what to do with your database and where to keep your secrets.

Which checks do you do before going live?

Before going live, you do one round that you take seriously and then repeat. The full list is in the basestep health check: eighteen points in five areas that you go through and tick off yourself. The platform does not watch along and does not check your site automatically; it gives you the list and the explanation, you do the work.

For a project that started with the interface, a few checks stand out. Remove all sample data, because a dashboard with made-up numbers on a real site is a promise you do not keep. Check that every form really arrives and that the input is checked on the server, not only in the browser. Go through the states outside the happy path: empty, loading, and failed. And do the round that ticks off accessibility and findability at the same time, because it is the same work. That means one h1 per page, heading levels in order, alt texts, usable with the keyboard, visible focus, enough contrast, and a title and description of its own for each page.

• Sample data out before you share the link.
• Forms arrive and are validated on the server.
• Empty, loading and failed states exist and look tidy.
• One h1, heading levels in order, alt texts, keyboard and contrast.
• HTTPS enforced, a clean 404, and no errors in the console.

The eighteen points are in the health check; the broader round is in the main guide.

What does v0 keep doing for you, and what is up to you?

v0 remains a pleasant place to come up with and revise interface. That is what the tool was made for, and that does not change because your project runs somewhere else. The boundary is simple to remember: as soon as code is in your project, your version is the truth.

In practice that means the following. Coming up with a new screen in the tool is always fine, but you take it over deliberately instead of overwriting a folder. What you adjusted yourself exists only in your project, so you keep track of it. Building, deploying and keeping it running are up to you and your host. You update dependencies at a fixed moment, because doing nothing for half a year turns every update into a renovation.

And basestep provides the guidance, not the action. The platform does not take your project live and does not check whether your site is running. It gives you the path in four phases, the health check to tick off yourself, and the administration, ready as soon as you earn. What you build stays yours and lives where you put it.

• With v0: coming up with and revising interface.
• With you: the project, building, deploying and maintenance.
• Take over new screens deliberately; never blindly overwrite what you adjusted yourself.
• A fixed moment for updates, and a monthly check that everything still runs and arrives.

What if your project starts making money?

As soon as money comes in, your project changes from something that works into a business with obligations. Bookkeeping comes with it: invoices that meet requirements, VAT (btw) that adds up per period, a record-keeping obligation for what you record, and a tax return you sign with your own name. That is exactly where basestep goes further than this guide, because the path does not stop at going live. It runs on from first prompt to first tax return, with a tax engine that explains every return box down to the legal reference. Set it up before the quarter ends, because bookkeeping you reconstruct afterwards costs more time than bookkeeping that keeps pace.

This is general information, not tax or legal advice. The tax explanation on this page follows Dutch law and is written for Dutch sole proprietorships (eenmanszaak). basestep calculates and explains; you file yourself.

How it works at v0 in August 2026

The rest of this guide is deliberately written to be timeless. This section is not. Here is what is true today and may be different in a few months, checked on 30 August 2026 in the documentation of v0 and of Next.js itself. Read it as a starting point, and check the source before you do anything irreversible.

The export model has shifted, and that is the most important news. Since February 2026 v0 revolves around projects instead of loose parts: your repository is the source of truth, and v0 does not keep its own copy of your code alongside it. Every message that changes something in the code is committed to a working branch, and you merge with a pull request. The old habit of pulling a part into your project with the shadcn command line is no longer described anywhere as the designated way. The documentation has moved too: the old addresses on vercel.com redirect you to v0.app.

• So your code is already with you once you have linked version control. Importing an existing repository has also been possible since February 2026.
• There is a documented endpoint in the programming interface that lets you fetch the files of a chat as an archive file. The screen itself has such a button too, but it is not described on any official page.
• Your v0 account is your Vercel account. Deployments, domains and environment values are therefore not v0 things but Vercel things, and you manage them there.
• Environment values do not come along in your repository or in an archive file. You transfer them by hand to your own host. With a linked database, you fetch them again from that service.
• Of the four database integrations, three are simply an account of your own at an external service, with a connection string that moves with you. Vercel's own storage service is not: it is tied to their own programming interface.
• Watch out for the service that has been in beta since 25 August 2026 and connects your app to other services without keys, using short-lived tokens. That is convenient, and it only works on Vercel's infrastructure. If your project leans on it, it runs nowhere else.
• On a free account there is a badge on your site that you cannot turn off.

Contrary to the common assumption: self-hosting Next.js does not cost you features. Next.js's own documentation, version 16.3.3 and updated on 25 August 2026, says that a Node server and a Docker container support all features. Only a fully static export is limited, because it cannot do anything that needs a server. So what you really lose when you move is not the framework's capabilities but the things tied to Vercel: their storage service, that new connection service, the management of your environment values and the previews per branch.

What we could not establish: whether the shadcn command line still works with a v0 address, which subscription a custom domain requires, and what exactly is in the archive file. Check that before you count on it.