---
title: "Why Vibe-Coded Apps Break in Production — Edgeware Global"
description: "Apps built with Lovable, Cursor or Claude work in the demo and fail with real users. The six failure patterns we see most, and how to check your own app."
url: https://edgeware.global/why-vibe-coded-apps-break-in-production/
---

Article October 20, 2026 6 min read

# Why Vibe-Coded Apps Break in Production

Apps built with Lovable, Cursor or Claude work in the demo and fail with real users. The six failure patterns we see most, and how to check your own app.

Looking to extend your engineering team with senior developers?

[Talk to us →](https://edgeware.global/contact-us/)

![Why Vibe-Coded Apps Break in Production](https://edgeware.global/images/why-vibe-coded-apps-break-in-production.webp)

Building software by describing it to an AI tool has gone from novelty to normal. Founders ship working products over a weekend; operations teams build their own internal tools; product managers prototype instead of writing documents. That is a genuinely good development, and nothing in this article argues otherwise.

But there is a pattern we see again and again: the app works perfectly for the person who built it, and starts failing the moment real users, real data and real money arrive. Not because AI tools write bad code, but because they are optimised for one thing — making the app work right now — and production asks for several others.

This article walks through the six failures we find most often when reviewing apps built with tools such as Lovable, Bolt, Replit, v0, Cursor and Claude Code, and how to check your own app for each.

## Why “it works” is not the same as “it’s ready”

An AI coding tool is rewarded for a green screen. You describe a feature, it produces code, you click around, it works, you move on. Every step of that loop pushes toward the shortest path to visible success.

Production cares about things that are invisible in that loop:

-   what happens when a _different_ user tries to see your data;
-   what happens when a thousand people do something at once;
-   what happens when the third-party API is down;
-   what happens six months from now when someone needs to change it.

None of these show up when you are the only user. All of them show up eventually.

## 1\. Access control that only exists in the interface

The most common serious issue, by a distance. The app hides other users’ data in the interface — but the database or API will happily return it to anyone who asks directly.

This happens because the tool built what you could see: a screen that shows your records. Whether the server enforces “only your records” is invisible from the screen, so it often does not.

**How to check:** log in as one user, find the request your browser makes to load data, and change the user or record ID in it. If you get someone else’s data, so can anyone else. If you use a hosted database such as Supabase or Firebase, check that row-level security or security rules are actually turned on and actually restrictive.

## 2\. Secrets in the browser

API keys for AI providers, payment services and email platforms end up in frontend code, where anyone can open the browser’s developer tools and copy them. An exposed AI provider key is particularly expensive: someone else’s workload runs on your bill.

**How to check:** search your frontend code and the built JavaScript for strings that look like keys. Anything secret must live on a server or in a serverless function, never in code that ships to the browser. Check your repository history too — a key deleted last week is still in git.

## 3\. Authentication with gaps

Sign-up and login usually work. The edges usually do not: password reset links that never expire, admin pages protected only by not being linked from anywhere, sessions that survive logout, or sign-up open to anyone when it should be invite-only.

**How to check:** try to reach every admin or internal page while logged out, and while logged in as an ordinary user. Try the password reset flow twice with the same link.

## 4\. A data model that will not survive growth

AI tools design the database for the feature in front of them. A few features later, you have duplicated fields, data stored as free text that should have been structured, no indexes, and no migrations — the schema was changed by hand, and nobody can recreate it.

This is not a security problem, but it is the one that most often forces an expensive rewrite later.

**How to check:** can you recreate your database from scratch, from files in your repository? Do your slowest pages get slower every week? Do you have backups, and have you ever actually restored one?

## 5\. No limits on anything

No rate limiting on sign-up or on endpoints that call AI models. No cap on file uploads. No spending limits on hosting or AI usage. In a demo, none of that matters. In production, one bot or one viral day can take the app down or produce an invoice larger than your monthly revenue.

**How to check:** look for rate limits on every endpoint that sends email, calls an AI model or creates accounts. Set billing alerts and hard caps with every provider that charges by usage.

## 6\. Code no one can safely change

The app works, but nobody — human or AI — can change one part without breaking another. The same logic is duplicated in five places, there is dead code from three abandoned approaches, and there are no tests, so every change is checked by clicking around.

This is the slowest-acting problem and often the most expensive. It is also where AI tools struggle most: with no tests to tell them they broke something, they cheerfully break it.

**How to check:** ask whether a change to one feature has recently broken another. If the answer is “regularly”, you need tests around the critical paths before you add more features.

## Most apps do not need a rewrite

When founders discover these problems, the instinct is often to throw the app away and “build it properly”. That is rarely necessary. In most apps we review, the core is reasonable and the serious issues are concentrated in a handful of places: the access rules, the secrets, the auth edges, the missing limits.

Fixing those is days of work, not months. The data model and maintainability issues take longer but can usually be addressed incrementally, with tests added around each area before it is changed.

## What a proper review looks like

A production readiness review is not a formal penetration test. It is a structured check, by someone who has seen production systems fail, of the short list of things that actually cause breaches and outages in small apps:

1.  **Read access** to the code, database and hosting — nothing changes during the review.
2.  **A review** of access control, secrets, authentication, data model, deployment, cost settings and maintainability.
3.  **A written report** ranking every finding by risk, explaining in plain language what it means and what fixing it takes.
4.  **A fix sprint** for the critical issues — done by the reviewer, or by you with the report as a guide.

If your app handles payments, health data or an enterprise customer’s security questionnaire, you may also need a formal penetration test; a review is good preparation for one.

We run these reviews as [vibe code rescue](https://edgeware.global/vibe-code-rescue/), led by our CTO. If you would rather check your own app first, the six sections above are the same list we start from. And once it is live, someone has to keep it that way — models change, dependencies age and costs drift, which is what ongoing [maintenance and support](https://edgeware.global/software-maintenance-and-support/) is for.

Looking to extend your engineering team with senior developers?

[Talk to us →](https://edgeware.global/contact-us/)

More articles

## Continue reading

[![Writing a Spec When AI Writes the Code](https://edgeware.global/images/writing-a-spec-when-ai-writes-the-code.webp)

Article · 5 min read

### Writing a Spec When AI Writes the Code

](https://edgeware.global/writing-a-spec-when-ai-writes-the-code/)[![What Is a Forward Deployed Engineer?](https://edgeware.global/images/what-is-a-forward-deployed-engineer.webp)

Article · 7 min read

### What Is a Forward Deployed Engineer?

](https://edgeware.global/what-is-a-forward-deployed-engineer/)[![Custom AI Model Development: A Guide](https://edgeware.global/images/custom-ai-model-development.webp)

Article · 9 min read

### Custom AI Model Development: A Guide

](https://edgeware.global/custom-ai-model-development/)

## Need engineers who can actually _ship?_

[Start a conversation](https://edgeware.global/contact-us/)