Lovable to production: code export and app security
For founders · Updated
Filip Papranecfounder of Digitaliko
You can take Lovable to production without rewriting what works. You clicked your app together in Lovable, the first people are trying it, and you do not know if it will hold up in production. Lovable code can be exported via GitHub and runs outside Lovable too. What usually is missing: data access control, backups, tests and operations. All of that can be added.
Vibe coding gets you a prototype. We build software that runs a business. Below: how to get the code out, what to check first and when to leave Lovable. What vibe coding is in general, we explain in Vibe coding: what it is and why software got cheap.
Can you export code from Lovable?
Yes. Lovable can connect a project to GitHub. The code then lives in your repository, and you can deploy it anywhere. The database and sign-in usually run in Supabase or Lovable Cloud.
We got the first point wrong ourselves once. Our prototype for a prospect ran on a personal account, and the link would have left with the person. Before you change anything, tick off what you already have:
Deploying outside Lovable is not step one. Security first, moving second, if at all.
Is a Lovable app secure?
You cannot tell without checking. The most common hole is not in the screens but in the database. Every visitor's browser gets a public key to the database. After that, only the access rules protect the data. In Supabase they are called Row Level Security.
If the rules are missing or let everyone in, one customer can see another customer's data. The app still looks fine. The bug shows only when someone goes looking for it.
This is what we checked when we audited a Lovable app:
| What to check | What bad looks like | What to do |
|---|---|---|
| Database access rules | A table with no rules, or a rule for "everyone" | Each user sees only their own rows, sensitive work goes through the server |
| Keys and passwords | A secret key right in the code | Outside the repository, and rotated if it was ever there |
| Sign-in and roles | Admin is recognised only by a hidden button | Role checked on the server, not in the browser |
| Payments | The browser marks an order as paid | Only the payment gateway confirms payment status |
| Backups | None, or never restored | Regular, and tested at least once |
| Operations | A customer reports the outage | The alert arrives before the complaint |
The general list for prototypes from any AI tool is in From a vibe-coding prototype to production. All checks in one place: Download the 25 checks before launch (PDF).
How do we do it?
Today AI writes all of our code. Filip is accountable for production. So the difference is not the tool. It is who reads what the AI wrote, and who is accountable when it runs for customers.
We have already audited a Lovable app. For a client, we also moved Lovable prototypes into a production app.
Small bugs crept in because the data layer under the prototype was completely different. The more context, the better the result: the prototype, a description of the feature and the data structure. So prototype as close to the real app as you can.
With a Lovable app we therefore do not start with a rewrite. We go in this order:
01
Check
Against the table above, data access first.
02
Security fixes
Data rules, keys out of the code, roles on the server.
03
A deployment you can repeat
Every change takes the same path, not a manual one.
04
30 days when it goes live
We stay with you until everything runs.
That is exactly what our MVP development for founders is about. If someone else built the app and you want to take it over completely, read How to take over an app from another vendor.
Stay in Lovable or leave?
At first, both. Lovable and GitHub stay in sync, so you can keep trying screens while we harden the rest. Your changes go through the same review as ours.
Leaving completely makes sense when the product grows and there are more changes than experiments. Then work usually happens only in the repository. Lovable stays a tool for quick sketches.
When we don't recommend it
- Only you and a few colleagues use the app. It does not need to go to production. Check the data rules and back up.
- You are still validating the idea and have no users. Keep going in Lovable yourself. Find a vendor once someone wants the product.
- You want to click new features in and check nothing. We cannot help with that. Code review is the reason to call us.
- You want someone to finish it for equity. We do not do that. Look for a technical co-founder.
What to prepare before the first call?
Three things are enough:
- access to the Lovable project or the GitHub repository,
- who uses the app today and for what,
- what has already broken, or what you are afraid of.
We get back to you within two business days, and together we pick what to fix first.
If you'd rather talk first, book a 15-minute meeting with Filip.
What would happen if someone looked at your customers' data tomorrow?
In short
- You get Lovable code out via GitHub. The repository, database and keys should belong to the company.
- The most common hole is the database access rules. Without them, one customer sees another customer’s data.
- A rewrite is usually not needed. Data access, backups, deployment and monitoring get added.
- At first you can stay in Lovable. As changes pile up, the work moves to the repository.
Frequently asked questions
How do I download code from Lovable?
Connect the Lovable project to GitHub, and the code is in your repository. From there you can deploy it outside Lovable. The database usually runs in Supabase and is exported separately.
Is a Lovable app secure?
You cannot tell without checking. The most common hole is the database access rules. The browser gets a public key, and only those rules protect the data. If they are missing, anyone can see the data.
Do I need to rewrite my Lovable app from scratch?
Usually not. More often it is enough to fix data access, get keys out of the code and set up backups, deployment and monitoring. Whether a rewrite is needed can only be said after looking at the code.
Can I keep using Lovable after a handover?
Yes, for a while. Lovable and GitHub stay in sync, so your changes and our fixes meet in one repository. Everything goes through the same review as the rest of the code.
Ask AI about this article
The AI also draws on our other articles and experience from real projects.
ChatGPTClaudePerplexity
