How to Take a Lovable App to Production

Getting something working is the part AI builders solved. Lovable, Bolt, v0 and Replit will take you from an idea to a clickable, demoable, occasionally even sellable application in a weekend. That is a real achievement and it is not worth being snobbish about.

The trouble starts at a specific and fairly predictable moment: when the app stops being a demonstration and starts being a system that real people depend on. Not when you hit hundreds of thousands of users — usually when you hit ten paying ones, or the first customer who cares about their data, or the first investor who asks an engineer to look at the codebase.

This is a checklist for that transition, in the order the problems actually bite.

1. Find out what your database is actually doing

This is almost always the first thing to break, and it is the most expensive to fix late because everything else is built on top of it.

AI builders generate schemas that work for the data they can see, which at generation time is nothing. The result is tables without indexes, relationships expressed as loose ID columns rather than enforced foreign keys, denormalised structures that made a demo query simple, and no migration history at all — meaning no way to change the schema safely once there is data you cannot lose.

Concretely, check for:

• Missing indexes. Any column you filter or join on needs one. A query that returns instantly against twelve demo rows can take several seconds against twelve thousand real ones, and that degradation is not linear.
• Unenforced relationships. If user_id is just a string column with no foreign key, you already have orphaned records. You simply have not looked yet.
• No migration history. If schema changes were made by asking the AI to change them, there is no record of what changed or how to reverse it. This is the single biggest blocker to safely evolving the app.
• Wrong types. Money stored as floating point, timestamps without timezones, enums as free text. All three cause bugs that surface as inexplicable one-off complaints.

2. Assume your authentication is wrong until proven otherwise

Generated authentication usually looks right, because the login screen works. What is frequently missing is authorisation — the part that decides whether this logged-in user is allowed to see this particular record.

The specific failure to look for, especially on Supabase-backed builds: row-level security left permissive or switched off entirely. The symptom is that any authenticated user can request any other user's data by changing an ID in a URL or an API call. The app looks completely normal from the inside. It is only obvious when someone goes looking, and by then it is a disclosure incident rather than a bug.

Test it directly rather than reading the code: create two accounts, log in as the first, and try to fetch the second account's records by ID. If you get data back, you have found your most urgent problem.

3. Get your secrets out of the repository

API keys, database URLs and service credentials frequently end up inline in generated code, then get pushed to a repository. If that repository was ever public — even briefly — treat every key in it as compromised.

Moving the values into environment variables is necessary but not sufficient: the old values are still in your git history, and history is trivially searchable. Rotate the keys themselves. All of them.

4. Work out whether you are repairing or rebuilding

This is the decision that actually determines cost, and it is worth making deliberately rather than drifting into.

Repair is usually right when:

• The data model is broadly sound — entities and relationships match how the business actually works, even if the implementation is sloppy.
• The problems are concentrated: auth, secrets, a handful of slow queries.
• The app does one thing, and that thing is well defined.

Rebuild is usually right when:

• The same business rule is implemented in several places with different behaviour, so no single fix is possible.
• The data model does not match reality and every feature needs a workaround.
• You cannot change anything without breaking something unrelated — the reliable sign that there is no separation of concerns to build on.
• The stack itself is a dead end for what you now need.

The instinct to preserve work is strong and often wrong. What is genuinely valuable in a prototype is not the code — it is the knowledge of what to build, which you keep either way. A rebuild that reuses that knowledge is much faster than the original build was.

5. Build the replacement in parallel, never in place

If you do rebuild, do not take the existing app down to do it. Build alongside, keep the original serving users, migrate data with verification on both sides, and switch traffic only once the new system has been tested against real production data.

This costs slightly more in setup and removes essentially all of the risk. A migration with a maintenance window is a migration with a deadline you will miss.

6. Only then, worry about scale

Most people worry about scale far too early and correctness far too late. Load is a good problem: it means people are using the thing. Getting the data model, security and deployability right first is what makes load a problem you can solve rather than a catastrophe you survive.

Where this usually lands

A realistic sequence for most AI-generated apps with early traction: audit first so you know whether you are repairing or rebuilding, fix authorisation and secrets immediately regardless of that answer, then either harden what exists or rebuild in parallel over roughly four weeks.

If you would rather not run that yourself, our AI App Migration service starts with a £995 Architecture Blueprint — a 48-hour audit that answers the repair-or-rebuild question with specifics, delivered as documents you keep whether or not you go further. Full migrations run £9,995 on a four-week fixed timeline.