Vibe-coded app broken? How to fix it

Why vibe-coded apps break

AI app builders are very good at one thing: making the screen you are looking at work. You describe it, it appears, you click it, it does the thing. That is a real achievement and I use AI tools every day myself.

The trouble is what you never look at. Nobody prompts "make sure user B can't read user A's invoices" or "handle the payment webhook arriving twice". So those things never get built. The app looks finished because everything you can see is finished.

A few patterns sit underneath almost every broken AI-built app:

• Every prompt is a local change. The tool edits what you asked about. Nothing holds the whole system in its head, so a fix to the dashboard quietly breaks sign-up, and you only find out when someone emails you.
• Only the happy path was ever tested. You built it logged in as yourself, on a laptop, on good wifi, with tidy test data. Real users arrive on a phone, on a train, with a typo in their email address.
• The code is confident. It compiles, it is neatly formatted and it reads like it knows what it is doing. That makes the gaps harder to spot, not easier.
• The fix loop. When something breaks, the natural move is to describe the bug and let the tool fix it. Each fix adds code without removing the cause. After a few rounds the app is bigger, slower and harder to change than it was a week ago.

None of this means you picked the wrong tool. Getting to something clickable is the hard first step, and you have done it. Getting to something strangers can sign up to and pay for is a different job, with a different checklist.

The ten things that break most often

These are the ten failures I look for first in any AI-built app. You can run every one of these tests yourself in an afternoon, without reading code.

Here is what each one usually looks like underneath, and what fixed looks like.

1. Auth

Login usually works. Authorisation usually doesn't. The app checks that you are signed in, not that the thing you asked for belongs to you. Many AI builders use Supabase as the backend, where the browser holds a public key by design. Supabase's own docs say that key is only safe because Row Level Security decides what it can reach. If those rules are missing, or written as "any signed-in user can read everything", anyone with an account can pull every row from the browser console. Other regulars: password reset links that point at a preview URL, admin pages protected only by not being linked, and roles stored somewhere the user can edit.

2. Data model

Tables get added one prompt at a time. You end up with the same thing stored in two places, names saved as text where they should be links to another table, no rules against duplicates, and prices stored in a way that rounds badly. It is fine with ten rows of test data. With real users, reports stop adding up and records go missing. Fixed looks like a schema you can draw on one page, with constraints in the database itself, not only in the form.

3. Payments

The classic one: the app upgrades the user when the success page loads. If the tab closes first, you take the money and the account stays free. Stripe sends payment events to a webhook, and its docs are clear that you should verify every event's signature, expect the same event more than once, and not rely on events arriving in order. Refunds, failed renewals and cancellations often have no code path at all.

4. Error states

AI tools build the state where everything worked. Empty lists, slow loading and failed requests get a blank screen or a spinner that never stops. And because errors are not logged anywhere, you hear about them from users, or more often you don't. Fixed looks like every screen having an empty, loading and error state, with errors reported somewhere you will actually see them.

5. Mobile layout

Most of these apps were built in a desktop preview. On a phone, tables run off the side, modals are taller than the screen, buttons are too small to hit and the keyboard covers the field you are typing in. Your first users will probably arrive from a link on their phone, so this is where first impressions are made.

6. Accessibility

Clickable divs instead of buttons, inputs with no labels, pale grey text on white, and focus outlines removed because they looked untidy. WCAG 2.2 asks for a contrast ratio of at least 4.5 to 1 for normal body text, and a lot of generated interfaces miss it. The same fixes help keyboard users, screen reader users and password managers, which all depend on proper labels and real buttons.

7. Exposed security keys

Anything shipped to the browser is public. I regularly see secret keys for payment, email or AI services sitting in front-end code, or in an env file committed to GitHub. Supabase's docs say a secret key should never go in a browser or in source control, because it bypasses every Row Level Security rule you have. Fixed means those calls move to the server, and any key that has ever been exposed gets rotated, not just deleted.

8. No tests

Without tests, every prompt is a gamble, and the fix loop above is the result. You don't need a huge test suite. You need a handful of tests around the journeys that make or lose money: sign-up, log-in, the core action, payment. They run before every deploy and fail loudly.

9. No design system

Each screen was generated separately, so there are five greys, three button styles and spacing done by eye. Users read that inconsistency as "not quite real", even if they can't say why. It also slows every future change, because nothing is shared. Fixed looks like a small set of colour, type and spacing tokens and a short list of components every screen uses. This is the part of the job I have done for over ten years as a product designer.

10. Slow load

Everything shipped to the browser in one large bundle, full-size images, and data fetched in a chain of requests after the page appears. Google's guidance is that the main content should load within 2.5 seconds. Fixed usually means rendering more on the server, sizing images properly and cutting the number of round trips.

What a fix looks like

A rescue is not a rewrite. The aim is to keep everything that works, fix what is dangerous first, and leave you with an app you can keep building on. The order matters: security and data first, then money, then the experience.

1. 1

   Free health check

   Run the vibe-code health check. It gives you, and me, a first read on where the app stands before anyone touches the code.

2. 2

   A call and a look at the code

   On a short call I learn what the app needs to do and who uses it. Then, with read access to the repository, I check the ten areas above properly.

3. 3

   Fixed price, in writing

   You get a short list of what I will fix, in what order, and one price. If something is better rebuilt than rescued, I say so here.

4. 4

   Fix the dangerous things first

   Exposed keys, auth and access rules, then the data model, then payments and webhooks. These are the ones that cost money or trust.

5. 5

   Then the experience

   Error states, mobile layout, accessibility, a small design system and load speed. This is where it starts to feel like a real product.

6. 6

   Tests and handover

   Tests around the journeys that matter, and written notes on what changed, why, and what to be careful with if you keep using the AI tool.

On timing: a Rescue Sprint usually takes about a week, depending on how much of the checklist fails. The price is fixed and agreed in writing after the free health check and a call. I don't quote a number before that, because two apps that look the same on the surface can be very different underneath.

You can keep using your AI builder afterwards. Most founders do. The handover notes tell you which parts of the code to leave alone, so the next prompt doesn't undo the fix.

If you want a first read before talking to anyone, run the free health check.

When a rebuild makes more sense

Sometimes a rescue is the wrong call, and I would rather tell you that before you pay for one. A rebuild usually makes more sense when:

• The data model is wrong at the root. For example, a two-sided marketplace built as if there were only one kind of user. Fixing that touches every screen.
• The product has moved on. If half the screens are for an idea you have since dropped, you would be paying to fix code you don't need.
• Most of the checklist fails. If seven or eight of the ten tests above fail, patching each one costs more than building it properly once.
• Someone else will inherit it. If you are about to hire developers or raise money, they will look at the code. A clean, conventional codebase is easier to hand over than a patched one.

In those cases the AI-built version is still useful. It is a working brief: it shows what you want better than any document. An MVP Build starts from £12,000 and takes 4 to 6 weeks, designed and built by me, in Next.js, TypeScript, Postgres and Stripe, on hosting in your name. If you want the wider picture first, read what an MVP costs in the UK, or see how I built my own marketplace in the FindPopups case study.