Your vibe-coded app has real users. Now what?

If your vibe-coded app has real users, run a security check this week, before you add another feature. Most apps then land in one of three places. Patch it if the problems are a few settings. Harden it if the bones are sound but nobody has checked the access rules. Rebuild it if the data model is wrong, payments are improvised, or no one can explain how it works.

The checklist below takes a non-technical founder about an afternoon. It won’t replace a proper review. It will tell you how worried to be, and what to ask for.

Updated 20 October 2026. We revise this whenever Lovable, Supabase or the other builders change their defaults.

Patch, harden or rebuild: the short answer

None of these is a failure. You proved people want the thing, which is the hard part. The question now is whether the code can carry them.

What the 2025–26 incidents tell you

The UK’s National Cyber Security Centre has taken a clear line. In March 2026, NCSC chief executive Richard Horne called vibe coding a “huge opportunity” to replace consistently vulnerable software. He also said AI coding tools must not introduce or propagate vulnerabilities. In June, an NCSC blog on the vibe coding spectrum drew the line founders need. Full vibe coding is often fine for prototypes and demos. Authentication, sensitive data and secrets need more rigour.

The incidents show why.

• Missing access rules, 2025. CVE-2025-48757 describes weak row-level security in Lovable-generated apps through April 2025. It let unauthenticated outsiders read or write database tables. It’s rated 9.3, critical. Lovable disputes it, saying each customer is responsible for their own app’s data.
• Inverted login logic, February 2026. The Register reported that an app featured on Lovable’s Discover page exposed 18,697 user records. One function blocked logged-in users and let anonymous ones through. Lovable said the project included code it didn’t generate, on a database it didn’t host.
• A platform flaw, April 2026. A researcher showed that any free Lovable account could read projects created before November 2025. The Next Web reported source code, Supabase credentials, AI chat histories and customer data were exposed. Lovable fixed new projects first, and the report says older ones stayed open for weeks.

Lovable has since added a pre-publish security scan and an Aikido penetration test at $100 a test. Both are worth running. Lovable’s own docs say they can’t guarantee complete security, and that apps holding sensitive data need a professional review.

If your app was built before November 2025

Assume anything inside the project has been read. That includes keys pasted into the chat, credentials in the code and the code itself. Rotate every key: Supabase, Stripe, email and any AI provider. Then check your database logs and your users’ data for anything you don’t recognise. Rotating keys costs an hour. Not rotating them could cost the company.

The 15-point afternoon checklist

You need admin access to your builder, your Supabase project and your Stripe account. You also need two test accounts that aren’t yours. Write down every answer, including “don’t know”. A “don’t know” counts as a fail.

Who can see what

1. Run the builder’s own scan. In Lovable, open the security view and run the scan. Read every finding, including the ones marked as ignored.
2. Row-level security on every table. Open each table in Supabase and confirm RLS is switched on. Supabase’s own guidance is blunt: a table without it is readable and writable.
3. The logged-out test. Sign out, open a private browser window, and paste in a link to a page that needs a login. You should be sent to sign in.
4. The two-account test. Sign in as test user A and copy the address of something private, like an order. Sign in as user B and open it. You should see nothing.
5. The self-promotion test. If users have a role, plan or admin field, find out where it lives. If it sits on a row users can edit themselves, anyone can make themselves an admin.
6. File storage. Check whether your storage buckets are public. Uploaded passports, invoices and photos should never be.

Keys and secrets

7. No secret key in the browser. Open the live app, press F12 and search the loaded files for service_role, sb_secret_ and sk_live_. Any match is an emergency. Rotate that key today.
8. Secrets have a second home. List every key the app uses. Each one should also be in your company’s password manager, not only inside the builder.
9. Spending limits. Every AI and email provider should have a monthly cap. A leaked key with no cap is a bill, not a breach.

Logins and payments

10. Login redirects. In Supabase’s auth settings, the allowed redirect addresses should be your real domains. Remove old preview links, localhost and wildcards.
11. Leaked-password protection and email confirmation. Both should be on. Lovable’s scan flags the first.
12. Stripe webhooks are verified. Ask your builder’s AI to show you where the webhook checks Stripe’s signature. Stripe’s docs warn that unverified webhooks let attackers fake events, like fulfilling orders or granting access.
13. Prices and entitlements live on the server. If the browser decides whether someone has paid, someone will decide for free.

Recovery and ownership

14. A tested backup. Find out where backups live and how far back they go. Restore one to a copy. A backup nobody has restored is a hope.
15. You own the accounts. The GitHub repo, Supabase organisation, domain, Stripe account and app store listings should sit under your company. Not a freelancer’s personal email.

How to read your results

Patch

Patch when you failed three or fewer checks, and they’re all settings. Typical examples are RLS switched off on a couple of tables, a stale redirect, no spending cap, or no password manager entry. A competent developer can fix these quickly. You can fix some yourself. Then re-run the whole checklist.

Harden

Harden when the app works, the data model makes sense, but access rules are thin or missing. You’ll usually see failures on checks 4, 5, 12 and 13 together. That pattern means business logic lives in the browser. Hardening moves it to the server, rewrites every access rule and adds tests that prove user B can’t see user A’s data. It also adds monitoring, so you hear about problems before your users do.

Rebuild

Rebuild when any of these is true:

• Nobody, including the AI, can explain how a payment becomes an account.
• Each fix breaks something else, and your credit spend is climbing every month.
• The data model can’t hold what you sell next, like teams, multiple sites or a second user type.
• An investor, enterprise customer or regulator is about to ask for a security review.
• You hold health, financial or children’s data on access rules you can’t vouch for.

A rebuild isn’t starting again. Your screens, user research, copy and customer list all carry over. What changes is the foundation under them.

What each route costs in pounds

Hourly work on a codebase nobody understands tends to grow. Ask for a fixed scope, or at least a cap. Our piece on fixed price vs time and materials explains why.

When rebuilding is cheaper than fixing

Rebuilding wins when you’d pay twice. You pay once to understand the code, then again to change it. Each fix needs someone to reverse-engineer what the AI meant, and that reading is the expensive part.

Three signals tip it:

• The hardening quote approaches a rebuild. If stabilising costs £30,000 and you’ll still rebuild in a year, the £30,000 bought a year.
• The roadmap needs a different data model. Bolting teams onto an app built for single users is slower than designing for teams.
• You need evidence, not reassurance. Enterprise buyers ask about audit readiness. Retrofitting ISO 27001 or SOC 2 controls onto unclear code is slow. We get clients ready for those audits; we don’t issue certificates.

If you’re unsure, keep the vibe-coded app running for current users while the replacement is built. Then move users across in one planned step. Our guide to what to do when an agency stalls covers parallel running in more detail.

Your UK GDPR position

If your app holds names, emails or anything else about people, UK GDPR applies. Your company is almost certainly the controller. The ICO defines a controller as whoever decides the purposes and means of processing. You decided to build the app and what it collects.

Lovable, Supabase and Stripe are your processors. That doesn’t move the responsibility to them. The ICO’s security guidance says you must choose processors that can show their security, and bind them in writing. The CVE dispute above makes the platforms’ view plain. They think your app’s data is your job.

Three practical consequences:

• Breach reporting. If a breach is likely to put people at risk, you must tell the ICO where feasible within 72 hours. Know who would make that call.
• The data protection fee. Most organisations using personal information must pay the ICO fee unless exempt. Check yours.
• Pre-November 2025 projects. If customer data sat in an exposed Lovable project, take advice on whether it’s reportable. Don’t wait to be asked.

This isn’t legal advice. It’s the list of questions to take to someone who gives it.

Handing a Lovable, Bolt or Replit app to a developer

Most handovers stall on access, not code. A developer can’t fix what they can’t reach. Get these sorted before the first call, and you’ll save days.

What a developer needs from you

Platform notes for Lovable

• GitHub. Lovable syncs with GitHub in both directions, on one branch. You can transfer the repo to your company’s organisation. Connect that organisation first, or Lovable disconnects the project.
• Download. On paid plans you can download the codebase without GitHub. Do it anyway, as a dated backup.
• Lovable Cloud. If you used Lovable Cloud, Lovable hosts the database. There’s no one-click move to your own Supabase. Export the data before you change anything.
• Supabase. To transfer a Supabase project, you must own the source organisation. The project also needs no active GitHub integration.

Bolt and Replit both offer export routes, and they change often. Check their current docs, then test that a fresh copy runs without the builder attached.

Keep building in the builder, or move out?

Some founders keep the builder for screens and let a developer own the backend. That works if one person decides what merges. Two people changing the same branch, one human and one AI, is how bugs get reintroduced. Agree the rule before the developer starts.

Ownership matters more than tooling. Our guide on who owns your code covers the contracts side. Whoever you hire, the accounts should be yours from day one.

After it’s fixed: who runs it

A fixed app still needs running. Keys expire, dependencies need updates, backups need checking and someone has to answer the 2am alert. With TotalCare, we run the product for a fixed monthly price. That covers hosting, app store accounts, third-party services, updates and support.

Where Contic fits

We won’t pretend to a back catalogue of vibe-coded rescues. What we have done is take over a platform from a previous supplier. For Electragram, we took it over mid-season. Inheriting code you didn’t write is the same job, whoever or whatever wrote it.

If a rebuild is the answer, LaunchPad is the fixed-price route. It runs Discover, Design, Build, Launch. Discovery sets the exact scope within your tier. If you aren’t confident in the plan after Discovery, you get your money back. The code, GitHub repos, AWS account and app store listings transfer to you.

Senior engineers review and own everything we ship, AI-assisted or not. That’s the NCSC’s point, applied to your app.

The first chat is free, and so is an architectural review. Bring your checklist results. Talk to us and we’ll tell you which of the three routes we’d take.