Your Lovable prototype works. Here is what it needs before real users.

Tools like Lovable, Bolt and Cursor have changed how products start. A founder can have a clickable app on a Tuesday afternoon, show it to ten potential customers by Friday and learn more than a month of slide decks would have taught them.

Then the question changes. People want to sign up, pay and come back. That is the moment a prototype has to become a product, and it is where most of the hidden work sits.

We build with AI ourselves every day, so this is not an argument against these tools. It is a checklist of what usually needs attention between "it works on my screen" and "customers rely on it".

1. Who can see which data

The most important question is also the easiest to skip. Create two test accounts and try to open the first account's records while signed in as the second. If that works, the app is not ready for real users, however good it looks.

Generated code often checks permissions in the interface and forgets the database or the API behind it. The fix is rarely large, but it has to be deliberate: rules for every table and every endpoint, tested with more than one user.

2. Secrets and keys

Prototypes collect API keys quickly: payments, email, maps, AI models. Check that none of them sit in the code that runs in the browser, and none were ever committed to the repository. A key that was deleted three commits ago is still in the history. Rotate anything that was exposed.

3. A data model that can grow

A prototype's database is shaped by the first demo. Before real data arrives, look at it with fresh eyes. Are users, accounts and roles separate concepts? Can you add a second team member to a customer? Can you delete a user cleanly when they ask you to? Changing this later, with live data in it, is far more expensive than changing it now.

4. Login, payments and email

These are the parts customers notice when they break. Password reset, email verification, failed payments, refunds, cancelled subscriptions and invoices all need to work, not just the happy path. Use the providers' own building blocks wherever you can instead of rebuilding them.

5. Knowing when something breaks

In a prototype, you find bugs because you are clicking through it. With real users, you need error logging and alerts, so you hear about a problem before a customer writes to you. Add backups, and test that you can actually restore one.

6. Updates as a routine

Every app depends on dozens of packages, and each of them gets security fixes. If dependencies are updated, tested and deployed through version control, a fix goes live in minutes. If updates depend on someone remembering, they do not happen. The recent PHP2Shell vulnerability is a good reminder of how quickly that matters.

7. An interface people trust

Generated interfaces tend to look alike: the same layout, the same cards, the same phrasing. That is fine for testing an idea. For a product that asks people for their data or their money, it costs trust. We wrote about the most common tells in signs of an AI-made product.

Keep, rebuild or start over?

Most prototypes do not need to be thrown away. A review of the code, the data model, security and the main user flows usually shows that some parts can stay as they are, some need rebuilding and a few need to be added. That picture is what makes the decision, and the budget, concrete.

• Keep what is isolated, readable and covered by the checks above.
• Rebuild what touches permissions, payments or the data model and was improvised for the demo.
• Start over only when the prototype has grown in so many directions that changing it costs more than rebuilding from what you learned.

The prototype did its job if it taught you what to build. The product is what you build next.

If you have a prototype that people want to use, our page for founders explains how we review it, make it production-ready and launch it with you.