Vibe Coding Rescue: What's Usually Wrong and What It Costs to Fix

“Vibe coding” is building software by describing what you want to Lovable, Bolt, v0, Cursor, or Replit and keeping what comes back. I ship most of my own code through Claude Code, so I'm in no position to lecture anyone about the method. It gets a non-technical founder to paying users faster and cheaper than an agency would. The trouble shows up later, and it usually arrives as a scare: a customer sees someone else's data, or an investor asks for access to the repo.

Founders in this spot tend to be afraid of two things. One is being told to throw the whole thing out and start over. The other is being judged for how it got built. Neither is how I work, and most of the time neither is warranted.

What's usually in the repo

A lot of these apps share a shape: a single-page React front end talking to Supabase directly from the browser, with no tests. That shape tends to produce the same problems:

• Row-level security as the only authorization layer, because the browser holds the database key, with policies loose enough that any logged-in user can read or write rows that belong to someone else.
• Server endpoints that use Supabase's service-role key, which skips row-level security entirely, without checking who is calling them.
• A migration history where a large share of the migrations exist to repair earlier ones.
• Columns that were added through the Supabase dashboard and that no migration creates, so the migration files can't be trusted as a description of the live schema.
• No step before deploy that would catch a broken build.

None of this is unusual for an app built this way. It happens when each change is a fresh prompt against code the model can only partly see, and nobody owns the parts users never look at.

Two corrections to the scary checklists that circulate about these apps. A Supabase anon key committed to a repo is usually fine, since it's designed to be public and every visitor's browser receives it anyway. The service-role key is the one that must never sit anywhere a browser or a public repo can reach it.

The second one catches people who think they're covered. Row-level security decides which rows a user can touch and says nothing about columns. Out of the box, Supabase lets a logged-in user update any column on a row they own. If your plan or is_verified field lives on the user's own row, they can change it with one request unless a migration has revoked that permission. I've had to close exactly that hole in one of my own products.

The order I go in

Security first: which keys exist, where they live, what each one can do, and whether every endpoint checks the caller. Then the data model, read from the live database instead of the migration files, for the reason above. Then the path that makes money: signup, payment, and whatever the customer is paying you for. Everything else waits until those are understood.

Fix it, rebuild part of it, or stop

In most rescues the UI survives nearly intact and the backend gets restructured underneath it, a piece at a time, while the app stays online. Founders often expect the reverse, since the UI is where they spent their attention.

When the browser-to-database pattern runs through everything, patching policies one at a time stops being worth it. My usual recommendation then is to put the customer-facing core behind a real API, so the browser never talks to the database and authorization lives in application code where it can be tested, and to move that core over one area at a time. Internal screens that only staff use can keep running as they are until someone has a reason to change them. The core is often a small fraction of the app, so this is a smaller job than the size of the repo suggests.

Sometimes the right answer is to stop. If one app has grown into a CRM, an ordering system, and a payroll tool at once with no structure underneath, and there's no budget to put one in, I'll say so and decline the work. Taking the money to polish it would only postpone the bad news.

After the rescue

AI tools will keep writing most of the code, and they should. What a rescued app needs afterward is a person who decides what gets merged and what goes to production, and tests on the logic that moves money or decides who can see what. That logic is where AI-written code most often goes untested, and it's the code you can least afford to get wrong.

If nobody on your team can own that, it's the job I do as a fractional CTO.

What the audit costs

A rescue starts with a $1,500 fixed-price audit. You get a written assessment of how the system fits together, what to keep as it is, the real problems ranked by which will bite first in production, and a sequenced plan to make it production-ready with a cost and timeline for each piece. If you hire me for the work, the $1,500 is credited against it.

I don't review codebases for free as part of a quote. Reading someone's code closely enough to tell them what's wrong with it is the first real piece of work on the project, and the fee tends to sort out who intends to fix the app from who is collecting opinions.

Sometimes the audit concludes the app isn't worth fixing. I'd rather you learn that for $1,500 than after a much larger invoice.