From AI prototype to production: how to make vibe-coded apps ready for real users

It nearly always starts the same way. A founder or an operations manager builds an app in Lovable or Bolt over a weekend. It works. Ten colleagues or twenty test customers use it, and the feedback is good. Then a user writes that she can see another customer’s orders, or the database bill jumps because someone found the API key in the browser. The prototype did exactly what it should: it proved the idea works. Now it has to be made ready for real people and real data.

Can an AI prototype go straight to production?

Rarely without a step in between. AI tools have become impressively good at screens, forms and simple databases, and they are an excellent place to start. They are weaker at the parts you cannot see: who may read which data, what happens when 500 users log in at once, how you roll back a bug, and who gets alerted when something goes down. We see it as a natural shift in a product’s life. The prototype is the phase where you learn what to build. Production is the phase where it has to work every day.

The good news is that the prototype holds real value in both scenarios. Even if the code has to be rewritten, you now have screens, flows and user feedback that would otherwise take weeks of workshops and wireframes. In practice, a working, clickable prototype is the best requirements specification a client can hand us.

What usually breaks when vibe-coded apps meet real users?

We have reviewed a fair number of AI-built apps, and the problems fall into four groups. Most of them are invisible in a demo, because a demo has one user, one browser and tidy test data.

Security: what a demo never reveals

The classic example is an app built on Supabase or Firebase where the frontend talks straight to the database. That is a perfectly legitimate architecture, but it assumes the access rules are set correctly for every single table. AI tools often create the tables and forget the rules, or they write one rule that lets every logged-in user see everything. That means anyone with an account and a little curiosity can open the browser’s developer tools and download the whole customer list. If your app holds personal data, that is a breach you are obliged to handle under GDPR. Read more in our guide to GDPR for websites and apps.

Data and structure: the debt that grows quietly

When you build by asking for one thing at a time, you get a data model that mirrors the order of the requests. The customer’s address lives on both the order and the profile. Status fields are free text. There are three nearly identical tables because the AI created a new one each time. It works fine at first, but every new feature costs more, and eventually the AI tool itself starts making mistakes because it can no longer see the whole picture. It is classic technical debt, only accumulated in record time.

Operations: who looks after the app at 3 a.m.?

A prototype typically runs on a free or cheap plan with the tool’s own hosting, on a database with no backup strategy and nobody receiving alerts. That is fine as long as no one depends on it. Once customers pay, or staff use the app in their daily work, you need to know where the data lives, whether it stays in the EU, how you restore it and who responds when something fails. Our guide to hosting data in the EU covers what to ask.

How do you check whether your AI-built app is production-ready?

Use this list as a first pass. It does not require coding skills, though some points require access to the database and the hosting account. If you cannot answer yes to a point, write it down. The list also makes a good brief if you want a supplier to assess the app.

1. The code lives in a Git repository on an account the company owns.
2. Database, hosting and domain are registered on company accounts with two-factor login.
3. Every table with user data has access rules, and they have been tested with two different users.
4. No secret keys can be found in the browser source.
5. Everything involving money, prices and permissions is validated on the server.
6. There is a staging environment where changes are tried before they reach real users.
7. Backups run automatically at least daily, and you have tried restoring one.
8. Errors are logged somewhere, and someone is alerted when the app fails.
9. Login is rate limited, so nobody can try thousands of passwords.
10. You know which personal data the app stores and where, and you have data processing agreements with your suppliers.
11. There is a privacy policy and a cookie banner that meets Danish rules if you use non-necessary cookies.
12. Someone other than the person who built the app can explain how it fits together.

If you get eight or more yeses, you are close, and the work is about closing the gaps. Under five is a sign that the prototype was built to demonstrate an idea, and the next question is whether to harden or rebuild it. Our software security checklist goes deeper on each point.

Should you harden the prototype or rebuild it?

This is the key question, and the answer depends on how the app is put together inside. We use four criteria: the data model, the technology, the size of the codebase and how much the app needs to grow.

What does it cost to make an AI prototype production-ready?

The price depends on the route you choose. The figures below are typical ranges when a senior developer in Denmark costs DKK 800–1,400 an hour. They cover the work itself and exclude the tools’ own subscriptions.

A concrete example: a cleaning company with 15 staff has built a booking and scheduling app in Lovable. It has customers, staff and an administrator, and it needs to send invoices to e-conomic. The review shows that customers can see each other’s addresses and that invoices are calculated in the browser. Here we recommend a rebuild, because permissions and billing logic belong on the server. The screens are reused almost one-to-one as the design, which typically saves a third of the design phase. With us, a solution of that size often fits a Medium package at DKK 36,000 plus DKK 900 a month, covering hosting, updates, backups and support.

How does the process from prototype to production work, step by step?

You can do step one yourself today, and it matters most. As long as the code and database sit on a private account belonging to whoever built the prototype, the company does not really own its own product. Our guide on who owns the code has an exit checklist you can use as is.

Which myths and red flags should you know about?

• Myth: It works, so it is done. An app that works for one user has only passed the easiest test.
• Myth: The AI can fix the security if we ask. It fixes what you ask for and often misses the rest. Security needs someone who knows what to check.
• Myth: A rebuild means the prototype was wasted. The prototype is the cheapest design work you will ever get.
• Red flag: Nobody can say where the database lives or who has access to it.
• Red flag: You are afraid to change anything because the last fix broke two other things.
• Red flag: A supplier wants to rebuild everything without having looked at the code. A serious assessment starts with a review.
• Red flag: The hosting or AI service bill rises while the number of users stays flat.

How do you keep using AI tools once the app is in production?

We use AI tools every day ourselves, and we recommend you keep going. The difference is in the workflow. Once the app has real users, changes should be small, pass through staging and be reviewed before they are rolled out. That keeps AI fast and makes it safe to use. Many of our clients use AI to sketch new screens or small internal tools, which we then bring into the real codebase. That way you get both: fast ideas and a stable product.

• Keep prototypes and production in separate branches or separate projects.
• Let AI write copy, test data and small components, and have a human approve anything that touches data and permissions.
• Write your rules down in a short file in the repository, so both the AI and developers work within the same frame.
• Review dependencies and keys every quarter.

If you are thinking more broadly about where AI fits in your business, read AI in your business: where to start. And if you have a prototype that needs to go further, send us the link. We build in React, Next.js and TypeScript, you own the code and data, and you get a fixed price within 24 hours, whether the answer is hardening or a rebuild.