Guide · Tech choices & rescues

Your vibe-coded app hit a wall: rescue it, rebuild it, or keep prompting?

A vibe coded app security checklist (RLS, exposed keys, auth gaps) and a scorecard to decide: keep prompting, rescue or rebuild your Lovable or Cursor app.

By Akash Bansal, founding engineerUpdated 4 November 20267 min read

Is your vibe-coded app actually broken, or just hard to change?

Most vibe-coded apps that "hit a wall" aren't broken. They are hard to change safely. The symptoms are familiar: every prompt that fixes one screen breaks another, the AI keeps rewriting the same file, nobody knows why the login sometimes fails, and you're afraid to touch payments. Those are structure problems. The dangerous problems are the ones you can't see from the UI at all: data anyone can read, keys anyone can copy, and pages that check who you are but not what you're allowed to do.

So this guide does two things. First, a security checklist you should run today, whatever you decide. Second, a scorecard for the actual decision: keep prompting, rescue, or rebuild.

Where I come from on this: I'm a senior engineer with about six years of production work, and I've done smart-contract security auditing, including a valid finding in a $63,000 Code4rena audit. Auditing teaches one habit that transfers directly to vibe-coded apps: assume the person using your app is hostile and has read your code, because with a browser's dev tools they effectively have.

The vibe-coded app security checklist

Run these seven checks before you decide anything else. The first three cause the incidents that make the news.

1. Is row-level security on for every table?

If your app uses Supabase or another Postgres backend that the browser talks to directly, row-level security (RLS) is the only thing stopping any visitor from reading or editing every row. Supabase's docs say RLS should always be enabled on tables in an exposed schema like public. Tables made in the Table Editor get it automatically, but tables created with raw SQL don't (Supabase docs).

This is not hypothetical. In 2025, Matt Palmer scanned 1,645 apps from Lovable's showcase and found 170 of them, about 10%, with 303 endpoints exposed by inadequate RLS. The leaked data included emails, payment details and API keys, and on one app a visitor could insert records marked as paid (Palmer's statement on CVE-2025-48757). To check yours, run this in the SQL editor:

select tablename from pg_tables where schemaname = 'public' and rowsecurity = false;

Every table it returns is open. Enabling RLS is only half the job. The policies have to limit each row to its owner or organisation, and AI-suggested policies are often too permissive (using (true) lets everyone through).

2. Are secret keys in the browser?

Open your live site, view the page source and the JavaScript bundle, and search for service_role, sk_, sk- and secret. Supabase's service role key bypasses RLS entirely and must only ever live on a server. The same goes for Stripe secret keys and LLM API keys. GitGuardian counted 28.65 million new secrets leaked in public GitHub commits in 2025, a 34% rise, and found that secrets for AI services grew 81% year on year (GitGuardian, State of Secrets Sprawl 2026). If a key has ever been public, rotate it. Deleting the commit doesn't help.

3. Does the server check what a user may do, not just who they are?

Broken access control is number one on the OWASP Top 10 for 2025. The vibe-coded version: the UI hides the admin button, but the admin API route only checks that you're logged in. Or the URL says /invoices/1042, and changing it to 1043 shows someone else's invoice. Test it yourself with two accounts. Platform-level gaps happen too: Wiz found an authentication bypass in the Base44 vibe-coding platform that let outsiders register on private apps using only a public app ID. Wix fixed it within 24 hours (SecurityWeek).

4. Are payments confirmed by the server?

The app should mark an order as paid only when your server receives a verified webhook from the payment provider, never because the browser said so.

5. Is user input treated as untrusted?

Veracode tested more than 100 LLMs on 80 coding tasks and found AI-generated code introduced security flaws in about 45% of cases. Cross-site scripting defences failed 86% of the time (Veracode, vendor research). Check that anything users type is escaped on display and parameterised in queries.

6. Are there backups you have actually restored?

A backup you've never restored is a hope, not a backup. Restore one into a scratch project once.

7. Do you own every account?

The code repository, the database, the hosting, the domain and the API billing should all be in your name. More on this in who owns the code.

Keep prompting, rescue, or rebuild: the scorecard

Once the security basics are known, the decision comes down to what state the foundations are in. Score your app honestly.

When should you keep prompting?

Keep prompting while the app is a prototype, a demo for investors, or an internal tool with no outside users, and while changes are still easy. This is the honest answer more often than people selling rescues admit. A Lovable or Cursor build that lets you test demand with ten users is doing its job. Don't pay an engineer to polish something you might throw away next month.

Two habits make this stage safer: commit to Git after every working change so you can roll back, and paste the security checklist above into your AI tool and ask it to verify each item. Then check its claims yourself with two test accounts.

When is a rescue the right call?

Rescue when the core works and the data model is roughly right, but the security, structure and deployment aren't production-grade. A rescue usually means: fix the checklist items, move secrets and privileged logic to the server, add tests around the money and permission paths, set up proper environments (development, staging, production) and deployment, and clean up the worst duplicated code so future prompts stop fighting it.

A good rescue keeps your momentum. You can usually keep prompting for UI changes afterwards, with an engineer reviewing anything that touches data, auth or payments.

When do you need a rebuild?

Rebuild when the data model is wrong for the business, because everything else sits on it. Common examples: you sell to teams but the database only knows individual users, bookings and payments live in different systems with no shared ID, or one table stores everything as unstructured JSON. Patching these costs more than starting the backend cleanly.

A rebuild isn't starting from zero. Your vibe-coded app is the best spec you could have: real screens, real flows, and real feedback from real users. A rebuild usually keeps the design and copy, rebuilds the backend and data model properly, and migrates the existing users. It rarely has to happen all at once, either: replacing one part at a time behind the live app is usually the safer route.

What does a rescue or rebuild cost?

A security pass on a small app is days of work. A full rescue is a multi-week project. A rebuild is priced like an MVP, but faster to scope, because the spec already exists. Your current app's feature list is enough to get a rough rebuild range from the app cost calculator. For market reference, one solo peer advertises a fixed six-week vibe-coding rescue at $12,000–$25,000 (rohitraj.tech, vendor source). My own published prices are an MVP from $15,000 (about 6–10 weeks), AI features from $8,000, and fractional CTO support from $6,000 a month. That last one is the right fit if you want to keep prompting while someone senior reviews every change touching data, auth or payments. For the line items, see what an MVP costs in 2026.

Whoever you hire, get a written diagnosis before a quote: what's wrong, what's risky, what's fine, and what they'd leave alone. If someone recommends a rebuild without explaining what's wrong with your data model, get a second opinion. How to vet a developer has the questions.

What should you do this week?

1. Run the RLS query and the key search above. Fix anything they find, or take the app offline until you can.
2. Rotate any key that has ever been in the browser or a public repo.
3. Test with two accounts: can user A see or change user B's data by editing a URL or an API call?
4. Move every account (repo, database, hosting, domain, billing) into your own name.
5. Score the app with the table above, and decide: keep prompting, rescue or rebuild.

If your app has real users and failed part of the checklist, this is work I do: a written diagnosis first, then a fixed quote, weekly progress you can see, and everything stays in your accounts. Here's how I work. If it passed and you're still testing demand, keep prompting. You don't need me yet.