Your Lovable prototype works: you click around and everything runs smoothly. But before a Lovable app goes to production, a team has to take over the code and the database, review security and decide whether to keep developing the prototype or build from scratch.
A working prototype proves the idea. Real customers are a different league when it comes to reliability. Vibe coding in a company, meaning building apps with natural language prompts in Lovable, Bolt and similar tools, cuts the road to a first version a lot. And that’s a good thing. I’m writing this for business owners and product managers who have a prototype like this and are looking for a team to take it further.
Table of contents
Where are the prototype’s code and database, and who has access to them?
The project code lives in Lovable. You can, however, connect it to a GitHub repository with two-way sync, or download it if you’re on a paid plan. As the Lovable GitHub integration docs explain, the repository created when you connect is private by default. Still, check that it sits in your company’s organization and not on the personal account of whoever clicked the prototype together.
Be careful when disconnecting the integration. Once you disconnect, syncing stops: the repository stays on GitHub, but any further changes are saved only in Lovable. That’s an easy way to end up with two versions of the code drifting apart. So before you hand over the code, agree on a single source of truth. Also list every person and account with access to Lovable, GitHub and the database. Permissions nobody needs? Revoke them.
What does the database export include, and what has to be moved by hand?
Under the hood, the prototype runs on PostgreSQL. According to the Lovable database export docs, the export covers the schema and the data, including user accounts. Sounds complete, but it isn’t. A working app depends on several things you won’t find in the export. You have to move these separately:
- files kept in storage, e.g. photos and documents uploaded by users,
- edge functions code, meaning functions that run on the server side,
- secrets and API keys for external services,
- login configuration and authentication providers.
Moving the backend to another provider is a job for a developer, not a single click. Put it in the plan and the budget from day one. Without these pieces, the app simply won’t start after the migration.
Security review of an AI-generated app: secrets, RLS and server logic
Rule number one: frontend code runs in the browser, so it can’t be in charge of security. And treat any secret that ends up in it as exposed. That’s how the Lovable security best practices put it, and that’s where the review has to start. Search the frontend code for keys and tokens, revoke them and move them to the server.
The second area is RLS (Row Level Security), the rules that decide which database records a given user can see, plus role permissions. The test question is simple: can a logged-in customer read or change someone else’s data? If so, you have a problem. Client-side validation doesn’t protect anything either. Business rules and data checks have to run on the server. We cover what fixing AI-generated code looks like in practice in a separate article.
Checklist before taking over the app’s code
Before the team takes over the code, it goes through a few areas that usually nobody cared about in the prototype:
- Ownership of the repository and database: the company’s organization, a list of accounts with access.
- Secrets and keys in the frontend code.
- RLS rules and role permissions.
- Logic on the server side instead of in the browser.
- Automated tests, which are usually missing.
- Backups of the database and files, and how to restore them.
- Costs of services running in the background: databases, functions, external APIs.
- Personal data: what is collected, where it goes and who can see it.
An app that processes customer data is subject to data protection law. In the European Union that’s the GDPR, and there’s no point pretending a prototype is exempt. Background services, in turn, are a permanent part of maintaining an AI-built app. Work out the app maintenance costs after launch right away, before the first invoice catches you off guard.
Extend the prototype or rebuild the app from scratch?
Extend it if the code and database structure is clear and the security fixes are isolated. If you’d have to touch the foundations, it’s better to treat the prototype as a specification. What speaks for extending it? A consistent data model. Logic that can be moved to the server. And a tech stack the team feels at home with.
Rebuilding makes sense when the logic is smeared across the whole frontend, there’s no access control, or you plan features the current architecture can’t carry. Even then, the prototype doesn’t go in the bin. It shows flows, screens and user needs that have already proven themselves, and that’s worth a lot. On that basis you can build the first version of the product on solid foundations.
How do you hand over an AI app prototype to a development team?
Start: access to the company repository, the database export and a list of items outside the export. Finish: a joint code review. Along the way, prepare a short description of the app’s purpose, a list of the features customers actually use (not the ones that were supposed to be there), known bugs and a list of accounts and external services.
The team taking over the project does the review, plans the backend migration, adds tests, sets up backups and takes on ongoing maintenance. Looking for a contractor for each of these stages? Here’s how we approach custom software development.
Lovable app to production: where to start
A prototype built with natural language prompts is valuable proof that the idea makes sense. It doesn’t guarantee stability under the load of real users, though. First the review against the checklist, only then the decision: extend or rebuild. All in all, it comes down to three things. Taking a Lovable app to production means sorting out code ownership, security and the decision about the future architecture.
Frequently asked questions
Does the code from Lovable belong to me, and can I move it?
You can sync the code with a GitHub repository or download it on paid plans. Just make sure the repo sits in your company’s organization and not on the creator’s personal account. Then handing the project over to a team is basically a matter of granting permissions.
Is the Lovable database export enough to move the app?
No. The export covers the schema, data and user accounts, but it doesn’t include files in storage, edge functions code, secrets, login settings or API keys. A developer moves those separately.
Is an app built in Bolt taken over the same way?
Generally yes, the review rules are the same: code, database, secrets, permissions and tests. Export details depend on the specific tool, so check its documentation before handing the project over.
