Where vibe-coded apps break: auth, permissions, and deployment

Vibe-coded apps break in three predictable places when real users arrive: authentication, permissions and deployment. Not the features, not the design, not the thing you demoed. The sign-in that does not really keep anyone out, the database that lets one customer read another's data, and the single environment with no way back from a bad change. This is what fails, why a demo hides all three, and how to tell if yours is safe to ship.

The point is not that AI coding tools are bad. They are very good at the part you can see. The trouble is that the three things above are the parts you cannot see in a demo, and a demo is all the feedback the prompt loop ever gets.

1. Authentication that does not enforce anything

A vibe-coded app almost always has a login page. Ask for one and you get one. What is usually missing is everything that makes a login mean something: email verification, real session handling, and, most of all, server-side enforcement. The page checks who you are; nothing checks it again when you ask the server for data.

So the sign-in works in the demo, and the moment someone opens the browser tools or guesses an API route, it stops mattering. Admin pages sit behind an unlisted URL rather than a permission. Password reset was never wired up. There is a users table, but no notion of roles.

What good looks like is dull and specific: verification on sign-up, sessions that expire and refresh, and every server route that returns data checking the caller's identity before it answers. Auth is not a screen. It is a rule that runs on the server, every time.

2. Permissions, or the day the second customer signs up

This is the expensive one. Most AI-built apps that use a hosted database ship with access control either missing or generated wrong, which means any signed-in user can query data that is not theirs. It looks perfect in the demo, because in the demo there is one user: you.

It becomes a breach the day a second customer signs up. On Supabase, the usual culprit, this is row-level security left disabled or written without testing, so the public key happily reads every row in the table. The dashboard even warns about it, and the warning gets dismissed because the app still works. It is the most common critical finding we see in Lovable apps.

Permissions are not a feature you add later. They are a property every table and every endpoint has to have from the first real user, tested per role: this person can read their own orders and no one else's, this person can write, this person can do neither. A build that has not been tested against someone poking where they should not is a build that has not been tested.

3. Deployment that is one environment called production

The third failure is operational. A vibe-coded app is typically deployed straight to one environment, which is production, with no staging alongside it and no rollback behind it. Every change edits the live app your users are on. A regenerated page can quietly drop the feature next to it, and the first monitoring system is a customer emailing to say something is broken.

Two related things travel with this. Secrets end up wherever they made the demo work, which is often the browser bundle, where anyone can read them. And there is no observability: no error tracking, no logs worth reading, no alert when a payment silently fails.

What good looks like is boring on purpose: a staging environment that mirrors production, deploys that can be rolled back in minutes, secrets held server-side, and enough monitoring that you hear about a failure before your customers do. None of it is visible in a demo, which is exactly why it gets skipped.

Why a demo hides all three

The common thread is that authentication enforcement, per-user permissions and a real deployment pipeline are the three things a demo never exercises. A demo has one trusted user, on one machine, making no mistakes, with no adversary. Production has strangers, at scale, some of them curious, one of them eventually malicious. The gap between those two situations is precisely the work AI tools skip, because nothing in a prompt-and-preview loop ever forces the question.

That is also why the fix is rarely "add a feature". It is closing the distance between a thing that works when you use it and a thing that holds when other people do. Sometimes that is a week of hardening. Sometimes, when the data model itself is wrong, it is a rebuild. The only way to know which is to have someone senior read the code and decide, rather than guess from the outside.

How to tell if yours is safe

Three questions, honestly answered. Can a signed-in user reach data that is not theirs? Are any secrets in the browser bundle? Can you roll back a bad deploy in minutes? If any answer is "not sure", the app is not ready for people who are not you, however finished it looks. That is not a failure of the tool or of you. It is just the part the demo could not show.

If you want the two-minute version, the free readiness scorecard walks through these and grades where you stand. If there are already real users and real money, the honest next step is a review: someone senior reads the actual code, from £1,500, and tells you whether it is a week of hardening or something more. Either way, the answer comes from reading the thing, which is more than a demo ever did.

Common questions

What does it mean when a vibe-coded app breaks in production?

Usually not a crash. It means the app works in a demo and fails the first time real, untrusted people use it: sign-in that does not actually keep anyone out, users able to see each other's data, or a deploy with no way to roll back a bad change. The failures are invisible until someone who is not you uses the product.

Why do AI coding tools miss auth, permissions and deployment?

Because a demo does not exercise them. AI tools optimise for the thing you can see working in the moment, and authentication enforcement, per-user access control and a real deployment pipeline are exactly the parts that never show up in a screen recording. They are skipped because nothing in the prompt loop punishes skipping them.

How do I know if my vibe-coded app is safe to launch?

Check the three: can a signed-in user reach data that is not theirs, are secrets anywhere in the browser bundle, and can you roll back a bad deploy in minutes. If any answer is "not sure", it is not ready. The free readiness scorecard is a two-minute version of that check; a paid review, from £1,500, is someone senior reading the actual code.

Can these problems be fixed without rebuilding the whole app?

Often, yes. Auth, access control and deployment can usually be hardened in place if the data model is sane and the code is readable. A rebuild is the honest answer only when the data model is wrong or the security has to be designed rather than patched, and that call should be made by reading the code, not guessing.

If what you have is a prototype built with Lovable, Bolt, v0 or a similar tool, the rescue hub sets out the route from here, and pricing is published in full.