The vibe-code rescue checklist

Why it matters

AI app builders make it easy to get something on screen. They don't make it easy to see what is missing behind the screen, because nothing you prompted for is visibly broken. The gaps are in the things nobody asked for: who can read which rows, what happens when a payment fails, what the app does on a slow phone.

This is the checklist I work through on an AI-built app before I recommend anything. It is ordered by harm. The first groups cover what can leak data or lose money. The later ones cover what makes the app hard to use or hard to change.

You can run most of it yourself in an afternoon. If you would rather work on paper, a PDF version of this checklist is available to download on this page.

How to use it

Go through each group and tick only what you have actually tested, not what you believe is true. "I think the keys are on the server" is an unticked box.

You will need:

• Two test accounts with different roles, or at least two ordinary users.
• A private browser window, so you can be both at once.
• Your phone, on mobile data.
• Stripe in test mode and a Stripe test card, if you take payments.
• Access to the database dashboard (often Supabase) and the hosting dashboard.

Write down every unticked item with one line on what you saw. That list is the brief for whoever fixes it, including you.

The checklist

This group matters most. Supabase's docs are direct about it: the publishable key is designed to be public, so Row Level Security on every table is what protects your data, and the secret key bypasses every policy, so it must never be in a browser or source control. You can find tables without Row Level Security in the Supabase SQL editor:

-- Tables in the public schema with Row Level Security switched off
select tablename
from pg_tables
where schemaname = 'public' and rowsecurity = false;

A typical owner-only policy, from Supabase's own docs, looks like this:

create policy "Users can view their own profile."
on profiles for select
to authenticated
using ( (select auth.uid()) = user_id );

There is more on this in vibe coding security risks and exposed API keys in AI code.

The two-account test is the quickest way to catch the most serious bug on this list. Log in as user A, copy the URL of one of their records, then open it as user B in a private window. If B can see it, stop and fix that before anything else. Fixing auth in an AI-built app covers what usually causes it.

Check backups before anything else changes. Supabase's docs list daily backups on paid plans and recommend that Free plan projects export their own data regularly. Fixing the database schema in an AI app goes deeper.

Stripe's webhook docs say to verify every event's signature, to expect the same event more than once, and not to rely on events arriving in order. An app that upgrades users when the success page loads breaks all three assumptions.

MDN notes that a fetch request does not fail on a 404 or 500 response, and Supabase's docs say its client returns errors instead of throwing them. Both are easy to ignore by accident. Adding the error handling AI tools skip has the code.

The numbers come from WCAG 2.2: 4.5 to 1 contrast for normal text, at least 24 by 24 CSS pixels for targets, and content that reflows at 320 pixels wide. Fixing broken mobile layouts in AI-generated UIs covers the Tailwind side, and making an AI-built app accessible the rest.

Google's Core Web Vitals call a page good when the largest content loads within 2.5 seconds, measured at the 75th percentile of visits. Why your AI-built app is slow explains the usual causes.

If you are handing the app over, how to hand a vibe-coded app to a developer turns this group into a full handover pack.

This last group is less about code and more about launch. It still belongs here, because it is where AI-built apps often ship with placeholders: a privacy policy generated before the product changed, emails sent from a default address that may land in spam, and no way to tell whether the launch worked. If you are planning a launch, GDPR for startups in the UK and the app launch checklist pick up where this list stops.

Common misses

These are the items people tick too quickly.

• Row Level Security switched on, with a policy that allows everything. The switch is green in the dashboard, but a policy like "any signed-in user can read all rows" means any account can download every row. Read the policies, don't just check they exist.
• Testing payments only with the happy path. The success page loading is not proof of payment. Close the tab, use a card that declines, and cancel a subscription.
• Rotating a key by deleting it from the code. If it was ever committed or sent to the browser, it needs a new value in the service's dashboard.
• Testing on a laptop with the window made narrow. It misses browser toolbars, touch, the on-screen keyboard and slow mobile data. Use a real phone.
• No restore test. A backup you have never restored is a hope, not a backup.
• Ticking boxes for things you were told. "The AI said it added validation" is not the same as trying to submit the form empty.
• Checking once and never again. Each new prompt can undo an earlier fix. A policy gets loosened to make a feature work, or a key moves back into the front end. Rerun the first two groups after any big change.

Next step

Count your unticked boxes in groups 1 to 4. If there are none, you are in better shape than many AI-built apps, and the rest can be fixed as you go. If there are several, fix those before inviting more users or spending on marketing.

If the list is long, the next question is whether to fix the app in place or start again: when to refactor vs rebuild a vibe-coded app helps with that, and what a vibe-code rescue costs in the UK helps with the budget. My guide to fixing a vibe-coded app explains why these failures happen in the first place.

The free vibe-code health check automates part of this list against your live URL. If you would rather have it done for you, a Rescue Sprint works through every group, fixes what is broken and leaves you with the list ticked, at a fixed price agreed after a technical assessment (from £750).