How to Fix a Vibe-Coded App: My Rescue Audit Checklist

Why do vibe-coded apps hit the 80/20 wall?

Because AI gets you 80% of an app in 2% of the time, and the last 20% is where vibe-coded projects die. The first 80% is CRUD screens, happy paths, and demo flows, which AI assistants generate well. The last 20% is auth edge cases, data integrity, concurrency, and security, which require decisions the AI was never asked to make.

A one-sentence definition, since the term gets used loosely: a vibe-coded app is an application built primarily by prompting an AI assistant and accepted based on whether it appears to work, rather than on review of the code underneath.

The pattern I see in every rescue is the same. The founder iterated fast, the demo looked great, early users signed up. Then growth exposed what nobody reviewed: a query that scans the whole table, a webhook with no signature check, three slightly different copies of the checkout component because the AI regenerated it instead of reusing it. None of this is visible from the UI. All of it is visible in an hour of reading code, if you know where to look.

AI-generated code does not fail randomly. It fails in the same five places every audit: secrets, auth, queries, duplication, and tests. That predictability is exactly why a rescue is cheaper than founders fear.

How big is the vibe-code rescue market in mid-2026?

Large enough that "vibe-code cleanup specialist" is one of 2026's fastest-growing engineering roles. As of June 2026, reports put it at ~8,000 of ~10,000 AI-built startup apps needing rebuilds or rescue engineering, with budgets running $50K to $500K and cleanup specialists billing $100 to $300 per hour.

The security side is what forces founders to act. One widely reported vibe-coded app breach exposed 1.5 million API keys because secrets were shipped in client-side code. That is not an exotic attack. It is someone opening DevTools, reading the JavaScript bundle, and finding credentials that should never have left the server.

Two things follow from those numbers. First, if you built your MVP with an AI assistant, you are statistically in the 80% that needs work, so an audit before launch is cheap insurance. Second, the hourly rates mean an unfocused engagement burns money fast. A scored, time-boxed audit protects the founder as much as it protects me.

What do I check in the first 60 minutes?

I run a seven-item triage and produce a 0-100 rescue score before quoting anything. Each item is checked with greps and a skim, not deep analysis. The score tells the founder in one number whether they have a cleanup, a surgery, or a rewrite conversation ahead.

Full marks means the item is healthy; zero means it is absent or dangerous. My reading of the total:

• 70-100: straightforward rescue, usually 2 to 4 weeks


• 40-69: rescue with surgery on one or two subsystems, 4 to 8 weeks


• Below 40: time for the rewrite-versus-rescue conversation below

How do I run the deep audit?

In a fixed order: security, then data integrity, then architecture, then performance. Security first because a breach ends the company; performance last because slow apps still have customers. Here are the actual commands, not abstractions.

Security. Find secrets that reached the client:

grep -rEn "sk-[a-zA-Z0-9]|SERVICE_ROLE|api[_-]?key|client_secret" \
  app/ components/ lib/ --include="*.ts" --include="*.tsx"

# Anything secret behind NEXT_PUBLIC_ is shipped to every browser
grep -E "NEXT_PUBLIC_" .env* | grep -iE "secret|service|private|key"

Then auth. In Supabase projects, the killer question is which tables have row level security disabled:

select c.relname as table_without_rls
from pg_class c
join pg_namespace n on n.oid = c.relnamespace
where n.nspname = 'public' and c.relkind = 'r'
  and not c.relrowsecurity;

AI assistants frequently scaffold tables and skip RLS, because the demo works fine without it.

Data integrity. I check for foreign keys that exist in the code's imagination but not the schema, money stored as floats, and status fields that are free-text strings. If orders.user_id has no constraint and no index, both integrity and performance are already compromised.

Architecture. Duplication grep plus a manual skim. grep -rn "function formatPrice" returning four results in four files is the classic tell.

Performance. N+1 queries hide in awaited calls inside .map():

grep -rn ".map(async" app/ lib/ --include="*.ts" --include="*.tsx"

And Postgres tells you where indexes are missing:

select relname, seq_scan, idx_scan
from pg_stat_user_tables
order by seq_scan desc limit 10;

I learned to trust these specific checks from running my own production systems. In my reputation SaaS, which syncs a few thousand reviews a month and generates AI auto-replies, an N+1 in the review-sync loop once turned a 4-second job into a 90-second one. Same class of bug, and the grep above would have caught it.

What fix order keeps the rescue from bankrupting the founder?

Fix in dependency order, cheapest stabilizers first, and never start with a rewrite. The goal is a safe, testable app, not a beautiful one. My order:

1. Stabilize. Add error boundaries, structured logging, and Sentry or equivalent. Pin dependencies and stop unreviewed upgrades; several rescues I have taken on were destabilized by a framework bump nobody read the changelog for, a failure mode I covered in my Next.js 16 migration guide on silent breakages ↗.


2. Secure. Rotate every exposed secret, move privileged calls server-side, enable RLS on every table, and put authorization middleware in one place instead of per-route copy-paste.


3. De-duplicate. Collapse the three checkout components into one. This is where future change costs drop the most.


4. Test the money paths. Signup, payment, and the core action users pay for. I do not chase coverage percentages; I write maybe 15 to 25 integration tests that would each catch a revenue-losing bug.


5. Performance. Indexes, N+1 fixes, and caching, guided by the queries from the audit, not by guessing.

What does a real rescue look like?

A representative case, anonymized: a B2B founder handed me a 95% AI-generated Next.js/Supabase app, around 38,000 lines, paying customers already onboard. Triage score: 46. The Supabase service-role key was referenced in a client component, 11 of 14 tables had no RLS, the pricing page logic existed in three diverging copies, and there were zero tests.

Six weeks, in the order above. Week one was rotation, RLS, and server-side moves. Weeks two and three were de-duplication and the test suite for billing. The rest was indexes and cleanup. Total cost landed near $22K, against a $120K rewrite quote the founder had already received from an agency. The app kept running the entire time, which matters when revenue is live; the same standards apply across my web development ↗ work, rescue or greenfield.

When should you rewrite instead of rescue?

My decision rule has three tests, and I only recommend a rewrite when all three fail: you cannot add tests because the code has no seams, the auth architecture enforces nothing centrally and would need to be rebuilt anyway, and the data model is incoherent, meaning no real constraints and the same truth stored in multiple places.

If the data model is coherent, rescue, even if the code on top is ugly. Schemas are the hard part to redo with live customers; components are cheap to replace incrementally. In roughly four out of five audits I run, at most one of the three tests fails, which means rescue wins on cost and risk.

The honest exception: pre-revenue apps with no users sometimes deserve a clean restart, because there is no migration risk to manage. That looks less like a rescue and more like my MVP development ↗ engagements, where the AI-generated version becomes a working spec instead of a liability.

Key takeaways

• The 80/20 wall is real: AI gets you 80% of an app in 2% of the time, and vibe-coded projects die in the last 20%.


• As of mid-2026, ~8,000 of ~10,000 AI-built startup apps reportedly need rescue work, at $50K-$500K budgets and $100-$300/hr specialist rates.


• Run the 60-minute triage first: secrets, auth, tests, queries, duplication, dependencies, error handling, scored 0-100.


• Fix in order: stabilize, secure, de-duplicate, test the money paths. Performance last, rewrite never as the default.


• Rewrite only when testability, auth architecture, and data-model coherence all fail. If the schema is sound, rescue.