Is your Lovable, Bolt or Replit app ready for real customers?

If your app was built with Lovable, Bolt, Replit, v0 or Cursor and people already use it, the honest answer to “is it ready for paying customers?” is usually not yet, but closer than you think. The same eight problems turn up in almost every AI-built app we review. Most of them can be checked in an afternoon, and very few require a rewrite. This checklist is for founders and product owners who want to know where they stand before customer data and revenue depend on the app. If you’d rather hand the whole review to someone else, that’s what our Vibe-Code Rescue service does.

“Vibe coding” means building software by describing what you want to an AI tool and accepting the code it writes, often without reading it line by line. It’s a genuinely fast way to reach first users. The catch is that the code is shaped by what you can see in the preview, so it tends to skip what you can’t see: access rules, error paths, backups, and what happens when a stranger calls your API directly instead of clicking through your interface.

What goes wrong when vibe-coded apps meet real users?

This isn’t theoretical. Some well-documented public examples:

• In 2025, researchers scanned 1,645 apps listed on Lovable’s public showcase and found 170 projects, about 10%, whose database rules let anyone read user data, and in some cases write it: emails, phone numbers, payment details and API keys. It was filed as CVE-2025-48757. Lovable disputed that it was a platform flaw, which makes the point rather than weakening it: getting the access rules right was each app owner’s job.
• Escape’s security team analyzed more than 5,600 publicly available vibe-coded apps, most of them built with Lovable, and reported over 2,000 high-impact vulnerabilities, more than 400 exposed secrets and 175 cases of exposed personal data, including medical records and IBANs.
• In February 2026, The Register reported on an education app featured by Lovable in which a researcher found 16 flaws exposing 18,697 user records. One critical check was inverted: it blocked logged-in users and let anonymous visitors through. The database had no row-level security.
• In July 2025, Replit’s AI agent deleted a project’s database during a declared code freeze. Replit responded by rolling out automatic separation of development and production databases.

The pattern shows up in controlled tests too. Veracode ran more than 100 language models through 80 coding tasks and found that in 45% of the tasks, the generated code introduced a known security flaw. AI tools write plausible code. They don’t reliably write safe code unless someone checks it.

The production-readiness checklist

These are the eight areas we check first in any AI-built app. The middle column is something you can do yourself, and most of these checks take minutes, not days.

Why is row-level security the hole we find most often?

Lovable and many Bolt and v0 projects use Supabase, where the browser talks to the database directly with a public key. That’s a legitimate design, but it only works if the database itself decides who may see which rows. The mechanism for that is row-level security (RLS): rules inside Postgres that filter every query by who is logged in. Supabase’s own documentation is blunt about it: enable RLS on every table in an exposed schema. Without it, anyone holding the public key, which ships inside your JavaScript, can read and write that table.

The variants we see most often:

• RLS is off on tables added later. The first tables got policies; the table the AI created for a new feature in week six didn’t.
• A policy exists but allows everything. A rule like using (true) counts as “has a policy”, so a scanner that only checks for presence passes it. When Lovable introduced its built-in security scan, the researchers behind CVE-2025-48757 criticized it for exactly this: it checked whether policies existed, not whether they were correct.
• Writes are left open. Even where reading is restricted, inserts and updates often aren’t. On Linkable, the first app identified in the CVE-2025-48757 research, a researcher wrote a record with payment_status set to paid straight into the database, bypassing Stripe entirely.
• The service-role key ends up in the browser, usually added “to make it work” when a policy blocked an admin feature. It bypasses RLS completely.

The fix is mechanical but needs care: a policy per table and per operation, admin actions moved into server functions, and an automated test that logs in as two different users and proves neither can touch the other’s data.

Which login and permission problems are easy to miss?

Login itself usually works, because you use it every day. The edge cases are what break:

• Permissions enforced only in the interface. Hiding the “Delete” button from non-admins does nothing if the API behind it accepts the request from anyone.
• Inverted or partial checks, like the education app above: code that looks right, passes a quick click-through, and does the opposite of what it should.
• Flows nobody clicks often: password reset links that never expire, email changes without re-verification, invitation links that can be reused, OAuth redirect settings that still allow localhost.
• Sessions that survive a role change or a deleted account.
• No rate limit on signup, login or password reset. That invites credential stuffing and, if signup triggers an email or an AI call, a surprise bill.

The general fix is to make the server the only place where permissions are decided, and to write one automated test per role that tries something the role shouldn’t be allowed to do.

What do GDPR and Nordic customers expect?

GDPR applies as soon as you store personal data about people in the EU, whatever your size. If a table of names and emails is readable by anyone, that’s a personal data breach, and when it’s likely to put people at risk it must normally be reported to the supervisory authority within 72 hours. In Sweden that authority is IMY.

B2B customers in the Nordics will also ask during procurement: where is the data stored, who can access it, which sub-processors receive it, and do you have data processing agreements in place? The gaps we typically find in AI-built apps:

• a database region nobody chose deliberately;
• analytics or session-replay tools recording form fields that contain personal data;
• customer data sent to an AI API with no agreement covering it;
• no way to export or delete one user’s data on request;
• logs full of email addresses and access tokens.

None of this is hard to fix, but it has to be written down, because your customers’ data protection officers will ask to see it.

Does a vibe-coded app need to be rebuilt?

Usually not. Most apps can be stabilized step by step while they keep running, and a full rewrite throws away the one thing the app has already proven: that people want it. We only recommend rebuilding a part when that’s cheaper over the next year than fixing it.

Signs that a part may be worth rebuilding:

• The data model is wrong at the root, for example a B2B app with no concept of an organization or tenant, so every query has to guess whose data it is. We cover tenant isolation and the other foundations in SaaS architecture from MVP to scale.
• The same business logic is copied into dozens of components, so every fix has to be made ten times.
• The code can’t be built or run outside the tool that generated it.

The trade-off between refactoring and rebuilding is the same one we describe for older systems in when to modernize legacy software. When we do move parts of an app, we usually move them onto the TypeScript stack we build on, which stays close to what the AI tools generate, so your team can keep using them.

In what order should you fix things?

If the checklist turns up problems, this order limits the damage fastest:

1. Today: rotate any exposed keys and turn on RLS for tables that have none. An open table is the one problem that can hurt you this week.
2. This week: confirm that backups exist by restoring one into a separate project, and separate development from production.
3. Next: move permission checks to the server and close the auth edge cases.
4. Then: put the code in a repository your company owns, with CI/CD and a way to roll back.
5. Then: tests for the flows that earn money, so the next AI-generated change can’t silently break them.
6. Alongside: the GDPR paperwork (data map, vendor agreements, deletion flow) and spending limits.

Once steps 1–5 are in place, AI tools become much safer to keep using, because a change that breaks login or opens a table fails the pipeline instead of reaching customers.

What to do next

Start with the checklist above; an afternoon with it will tell you more than any automated scanner. If you’d rather have a senior engineer do it, our Vibe-Code Rescue starts with a fixed-price code and security audit for €1,900 (3–5 business days), which gives you a written report with prioritized fixes and a fixed price for making them; the fee is credited if you go ahead. Stabilization starts from €6,000 and typically takes 2–4 weeks. After that you can keep the app maintained with Care Lite, our fixed-price monthly maintenance plan, keep building with a Start Pod, a small senior-led team at a fixed monthly price, or take everything in-house. You contract with Smoother Development AB in Sweden, our engineers work from Ukraine, and a founder is accountable for the work.