Taking a Lovable, Bolt or Base44 app to production

Taking a Lovable, Bolt or Base44 app to production means turning a demo that works into a service customers rely on. The path comes down to three verbs, applied module by module: keep what users have validated (screens, flows), harden what is fragile (access rules, data, secrets), and rewrite only what would cost more to fix than to rebuild. You do not have to abandon the tool. But it will not do this part of the work for you.

This guide is for founders and operators who already have a prototype, sometimes with early users, and want to know what is missing before opening the doors. It is not a case against these tools. They are built for speed, and they deliver it.

What your prototype already proves

An AI-built prototype is worth more than many people think: it proves the need. The screens, the order of steps, the data involved, the words your users actually use are all decided and visible. In a traditional project that is the slowest part, and you have already done it.

What the prototype does not prove:

• that one customer's data is invisible to another;
• that the app holds up when a hundred people use it at once;
• that tomorrow's change will not break what works today;
• that you can restore your data after a mistake;
• that someone will be there to fix an incident on a Sunday.

The gap between those two lists is what "production" means. If you are not sure you need to close it, start with AI app builders vs a software studio. This article assumes you do.

What the vendors say themselves

The platforms are explicit about who is responsible. Lovable's security documentation says it plainly: "You are responsible for ensuring that your app meets the security requirements appropriate for its use case." It adds that its scanners cannot guarantee complete security and recommends a professional review for apps that handle sensitive data or critical functions.

The risk is not hypothetical. In May 2025, CVE-2025-48757 was published: insufficient row-level security policies in apps generated with Lovable let unauthenticated visitors reach data. Lovable disputes the classification, but the point stands. The builder generates; you answer for what is live. Our security checklist for a vibe-coded app covers what you can verify yourself before launch.

The grid: keep, harden, rewrite

Split the app into modules and run each one through the grid. It avoids the false choice between "ship everything as is" and "start over".

Keep

Screens your users have validated are almost always kept. Redesigning them adds nothing at launch and throws away what you learned. Fix mobile layout and accessibility; do not start a redesign.

Harden

This is most of the work. Hardening means keeping the code and structure while adding what is missing:

• verified access rules on every table. Most of these builders sit on Supabase or something similar, and Supabase's documentation says to enable row-level security on every table in an exposed schema; without it, the table is readable and writable by any role with a grant;
• automated tests on the rules that matter: a price, an order status, a permission;
• a test environment separate from production, so an experiment never touches real data;
• monitoring, so you hear about an error before your customers do.

Rewrite

A module gets rewritten when fixing it would cost more than rebuilding it, or when it carries a risk nobody can measure. In practice that is often payments (subscriptions, refunds, provider webhooks) or a permission system that became unreadable after dozens of conversational fixes. The rewrite stays targeted while the rest of the app keeps running.

Start with an audit

Before deciding, look. Auditing a generated app follows the same method as any software takeover, described in auditing an existing application before a takeover, with three areas that matter more with AI builders:

1. Database rules. They tend to be written once, early on, and never revisited while the app grows.
2. Secrets. An API key pasted into a chat can end up in code shipped to the browser. Supabase's documentation is clear that a secret key must never be used in the browser.
3. Dependencies added along the way. Each request can pull in a library. Some are no longer used; others are no longer maintained.

The output is a prioritised list: what blocks the launch, what can wait, and where each module sits in the grid.

Getting your code and data out

Going to production does not mean leaving the platform. But you need to be able to leave, if only so someone else can review the code.

• Code. Lovable's plans page lists Git sync (GitHub, GitLab, Bitbucket) on every plan. Bolt's GitHub integration backs up the project with its full change history. Base44's GitHub sync requires the Builder plan or higher.
• Data. This is the tricky part. The Lovable Cloud documentation says a project does not move to your own Supabase project in one step: you export the database, restore it, move storage files, then reconfigure authentication and secrets. Bolt's help centre states there is currently no supported way to migrate an existing Bolt database to Supabase.
• Runtime. Code exported from Base44 relies on the Base44 SDK, described as an interface for building apps on the Base44 platform. Having the code is not the same as running it elsewhere without extra work.

None of this rules a tool out. These are decisions to make before launch, not on the day you need to leave in a hurry. Our exit plan guide lists what you should be able to recover from any vendor. For a side-by-side view of the three platforms on these points, see Lovable vs Bolt vs Base44.

Operations start on launch day

A production app is alive. None of the following exists in a prototype, and all of it should be in place before the first paying customer:

• Backups, and above all restores. A backup that has never been restored is an assumption. Try it once, on the test environment.
• Error logging. Knowing that a payment failed, when, and for whom.
• Updates. Libraries get security patches; someone has to apply them and check nothing breaks.
• Support. Who answers a stuck customer, and how fast.
• Legal basics. Terms, a privacy notice, and, if you serve customers in the EU or UK, your obligations as a data controller under GDPR. Our business application security essentials covers the technical side.

Signs you have reached the limit

Some signals mean it is time to move from building by prompt to building with a team, whichever tool you started with:

• each new feature breaks an older one, and nobody notices until a user complains;
• you hesitate to change anything before a customer demo;
• the same bug comes back after being "fixed" several times;
• a prospect asks for a security questionnaire, a data processing agreement or a hosting location, and you cannot answer;
• usage costs keep climbing because most prompts are now corrections.

None of these is a failure. They are what success looks like for a prototype that has found its users.

The most expensive mistakes

• Fixing by chat in production. One prompt can change several files. Without a test environment, a button fix can break an access rule.
• Opening to everyone at once. Start with a handful of trusted customers, watch, then widen.
• Starting over on principle. Throwing away a working prototype wastes weeks of learning. The grid exists so you only rewrite what must be rewritten.
• Keeping everything to save money. Shipping without testing data access is a bet placed with your customers' data.

How we approach these projects

At LPR Studio, a prototype built with Lovable, Bolt or Base44 is a great starting point: it shows what you want better than any specification. We review it with you, then present a free prototype of the production version over video within 5 business days, with each module placed in the grid. Rights to the code we produce are defined case by case in the contract. We use AI to write code too; the difference is the verification around it, and the fact that we build and run our own software products ourselves.