Your Lovable app works. Production is a different question.

We like Lovable. Part of this site started life in it. An AI builder that takes you from prompt to deployed app in an afternoon is genuinely useful, and the people dismissing the whole category are wrong.

But there is another version of the story. The app demos beautifully, the founder has sold it to their first real customer, and now something is wrong that another round of prompting will not fix. The problems underneath are boringly consistent, and most of them are documented in public audits rather than our opinion.

The database is open

This is the big one. Lovable pairs with Supabase, and Supabase's security model rests on Postgres row level security: the browser talks to the database API directly, and RLS policies are the only thing deciding who gets what. The AI creates your tables. It does not reliably write your policies. Tomer Goldstein audited 50 public Lovable apps and found 89% without working RLS, meaning any logged-in user could read, edit, or delete any other user's data by calling the Supabase API directly. A third of the apps had the service role key, which bypasses every security rule, sitting in the JavaScript bundle for anyone to lift. No hacking involved. The frontend hides the data; the database hands it over.

To be clear, the platform is not the problem. We ship client products on Supabase ourselves, BriefQR and MedMaster among them. The problem is generated defaults that nobody audited. If your app has real users and you have never read your RLS policies, assume this applies to you. It is a day or two of work to fix and it is not optional.

It was built for one user

AI builders optimize for the demo: one user, happy path, empty database. Production is many users, weird input, and a table that grows. The symptoms show up in a predictable order. Auth edge cases first, because password resets and OAuth callbacks were never tested. Payments next, because the webhook handler silently drops events it does not recognize, or double-charges when Stripe retries one it already processed. Then queries get slow, because nothing has an index and nobody noticed while the table had forty rows.

None of this means the app is garbage. It means the AI did the first 70% and nobody did the rest. The remaining 30% is boring: indexes on the columns you filter by, webhook handlers that check the event ID before acting, error handling that surfaces failures instead of swallowing them, and an environment to test in that is not also the production database.

Prompting past the ceiling

There is a moment in every stuck project where the chat log gives it away. The same feature has been rebuilt four times. Each prompt fixes one thing and quietly breaks another, because the model no longer fits the whole codebase in its head, and neither does the founder. More prompting from this position makes the code worse.

What works is unglamorous. A person reads the code, writes down what the app actually does, deletes the dead ends, and puts tests around the parts that make money. Then the AI tools become useful again, because the codebase is small and coherent enough to reason about.

What we'd check before launch

If you built something with Lovable, Bolt, or Cursor and money or user data is about to touch it, this is the pre-flight list we run:

• RLS enabled on every table, and tested by calling the API as a second user, not just switched on
• No service role key anywhere the browser can see it, including old commits
• Auth flows tested past the happy path, including reset and account deletion
• Payment webhooks idempotent and logged
• A staging environment that is not production
• Error tracking, so the first report of a bug is not a customer email

Nothing on that list is hard, and together it is the difference between a demo and a product. If you would rather hand it over, legacy rescue is literally on our services list, and the work is a lot cheaper before launch than after.