Turn a v0 design into a product that works.

v0 is aimed at the interface: the layout, the components and how a screen responds when you click. It does that part quickly and the results are often good enough to show to customers. A product also needs somewhere to keep each customer's information, a way to know who is signed in, rules about who may see what, and connections to payment and email. Unless you built those separately, they are probably absent, and the screens are showing you placeholders where they would go.

This is the expected state of a generated interface. Where founders lose time is in not knowing which parts are real, so the work ahead looks either trivial or endless. The table names the usual placeholders and how to recognise each one from the outside.

You can find out how much of the product exists in one short sitting, from a browser, with no technical knowledge. Run these on the deployed address if you have one, or on the preview.

The reload test: add something through a form, such as a new project or a customer name, then reload the page. If your entry is gone and the original sample rows are back, nothing is being stored.

The second device test: open the same address on your phone, or in a private window, and look for what you added on the first device. Information that shows on one device and not the other is being kept in that one browser. It will not follow a customer from laptop to phone, and you will never see it yourself.

The wrong password test: sign in with an email address you have never registered and a made-up password. If you get in, there is no real sign-in yet. Then sign out and paste the address of an inner page, such as the dashboard, into the address bar. If it opens, the pages are unprotected whether or not the sign-in form works.

Order matters because each layer depends on the one below it. Stored data comes first: create the database from your inventory and connect one screen to it so that an entry survives a reload. Sign-in comes second, together with the rule that each record belongs to an account, because adding ownership to records later means revisiting every screen. Payments come after both, since a purchase has to be recorded against an account that exists in a database that exists. Email and notifications can follow.

Build one journey through all the layers before widening. A single path that works from sign-up to the stored result teaches you more about what the rest will take than six screens each half connected. Keep the interface code you have. Replacing sample rows with fetched data usually changes a small part of each component and leaves its appearance alone.

Some of this must run on a server. Checking a password, deciding whether someone may read a record and talking to a payment provider cannot be left to code in the browser, where a visitor can alter it. If the project so far consists only of interface components, plan for a server side from the start. Tools and hosted services exist for each layer, and which combination suits you depends on the product.