Your AI-Built App Broke When Real Users Arrived: What to Do Next (Harden, Rebuild, or Walk Away)
In 2026, building an app no longer requires a developer. Lovable, Replit, Bolt, v0, Cursor, and a dozen similar tools will turn a paragraph of English into a working product in an afternoon. Thousands of founders and small businesses have done exactly that — and a growing share of them are now searching for the same thing: someone to fix it.
This guide is for the people in that position. It's written by a team that takes over AI-built codebases for a living — and that uses the same AI tools every day. We're not here to tell you vibe coding was a mistake. We're here to tell you what usually breaks, how to decide between fixing and rebuilding, what each path costs, and how to avoid paying twice.
Why it worked in the demo and broke in production
AI code generators are optimised for one thing: making the thing you asked for appear on screen. They are very good at it. What they are not optimised for is the invisible 80% of a real product — the part that only matters once strangers start using it.
An AI-built app typically works perfectly for:
- One user at a time
- Clean, expected inputs
- A small amount of data
- A friendly environment where nothing goes wrong
Production is the opposite of all four. The failure is not random; it follows a pattern we see in almost every codebase we take over.
The seven things that are usually wrong
1. Secrets in the front end. API keys, database credentials, payment tokens sitting in client-side code where anyone can read them from the browser. Research on AI-assisted commits found they leak secrets at roughly twice the rate of human-written ones. This is the first thing we check, and it's wrong more often than not.
2. Authorization that doesn't exist. Login works. Access control doesn't. User A can request User B's data by changing an ID in the URL. In 2025, a flaw of this type on one popular AI app platform exposed data from more than 170 production apps at once.
3. No real backend. Business rules live in the browser, where they can be bypassed. Subscription checks, limits, and validation are enforced client-side only — which means they aren't enforced.
4. No tests, no staging. Changes go straight to production because there's nowhere else for them to go. Every fix is a gamble.
5. A data model that was never designed. Tables were created one prompt at a time. There are no migrations, no constraints, and no plan for what happens when the schema needs to change.
6. Hard-coded everything. URLs, limits, prices, and the AI model name itself are baked into the code. Changing any of them means a developer and a deploy.
7. Nobody knows how it works. Including the person who built it. There's no documentation, no architecture, and the AI that wrote it doesn't remember.
Independent scans back this up: one security firm's audit of 5,600 AI-built apps turned up more than 2,000 vulnerabilities, and a separate analysis found that close to half of AI-generated code contains at least one security weakness.
The real question: harden, rebuild, or walk away?
Most people assume they need a full rebuild. Most people are wrong. The honest answer depends on what's actually in the code, and there's only one way to find out: an audit before any decision.
An audit is a senior engineer spending one to three days reading the code, running the app, scanning for vulnerabilities, and mapping the architecture. The output is a written report that sorts findings into three buckets:
Harden (the most common outcome). The product logic is sound, the front end is usable, but security, backend, and infrastructure need to be done properly. Typical scope: move secrets server-side, implement real authorization, add a proper backend for business rules, set up staging and tests, add monitoring. Two to four weeks of senior engineering.
Partial rebuild. One layer is unsalvageable — usually the data model or the backend — but the front end and the product flows are worth keeping. Rebuild the broken layer underneath; keep what works. Four to eight weeks.
Full rebuild. The architecture is duct tape all the way down and every change breaks two other things. Rebuilding on a clean foundation, using the AI-built version as a detailed specification, is faster and cheaper than patching. The original wasn't wasted — it's the best product spec you'll ever hand a developer.
Walk away. Sometimes the audit reveals that the product idea isn't validated yet, and the right move is to keep using the prototype as a prototype — not pay to productionise something that doesn't have users.
A good partner will tell you which bucket you're in before quoting the work. If someone quotes a rebuild without reading the code, that's a sales number, not an engineering one.
What it costs
Rough 2026 ranges for a typical small-to-mid-size AI-built app, with a professional team:
| Path | Typical cost (USD) | Timeline |
|---|---|---|
| Audit only | 1,500 – 4,000 | 2–5 days |
| Hardening sprint | 5,000 – 15,000 | 2–4 weeks |
| Partial rebuild | 15,000 – 40,000 | 4–8 weeks |
| Full rebuild (MVP scope) | 25,000 – 80,000 | 8–16 weeks |
For comparison: the cost of a security breach, a wiped database, or a failed investor technical review is, in our experience, a multiple of any number in this table. One widely reported incident in 2025 involved an AI coding agent deleting a live production database during an explicit code freeze. The business survived; many don't.
When to get the audit
Not when you finish building. When something is about to be at stake:
- Real users are about to arrive (launch, marketing push, app store listing)
- Real money is about to flow (payments, subscriptions)
- Real data is about to be stored (personal data, business data, anything regulated)
- An investor, partner, or enterprise customer is about to look at your code
Any one of these is the moment. Before that, keep vibe coding — it's the fastest validation tool ever built.
How to choose who fixes it
Red flags:
- A fixed price before anyone has read your code
- "Rebuild from scratch" as the first and only option
- A team that will also vibe code the fix — you'll be back in six months
- No mention of tests, staging, monitoring, or documentation in the proposal
- No clear statement that you will own the code and the infrastructure
What you want:
- Audit first, decision second, quote third
- Senior engineers who use AI tools and know what they get wrong
- A written report you can hand to another team if you choose to
- Two-week increments with something deployed at the end of each
- Everything in your own accounts: repositories, cloud, app store, domains
How we handle AI-built codebases at UmaySoftware
Taking over existing code is a core part of our work, and in 2026 a large share of it arrives from Lovable, Replit, Bolt, and Cursor. We use the same tools ourselves — the difference is that a senior engineer owns the architecture, the security model, and the review, and the AI does the typing.
Our process is the one described above: a fixed-price AI-built app audit first, a written report that says harden / partial / rebuild / wait, and only then a scoped quote. If the audit says "keep going on your own," we'll say that too.
If your app is live and you're not sure what's underneath it, send us the repository link. The audit takes a few days and you'll know exactly where you stand.
Frequently asked questions
Can an app built with Lovable, Replit, or Bolt go to production?
Yes, but almost never as-is. The front end and product flows are usually fine; the security, backend, and infrastructure typically need professional work. A hardening sprint is the most common path.
Do I have to rebuild my vibe-coded app from scratch?
Usually not. In our experience most AI-built apps need hardening or a partial rebuild, not a full rewrite. The decision should come from an audit, not an assumption.
How much does it cost to fix an AI-generated app?
An audit runs 1,500–4,000; a hardening sprint 5,000–15,000; a partial rebuild 15,000–40,000. A full rebuild at MVP scope is 25,000–80,000. These are 2026 ranges for a professional team.
What are the most common security problems in AI-generated code?
Secrets embedded in client-side code, missing or broken authorization (users able to reach other users' data), and business rules enforced only in the browser. Hard-coded credentials are the single most frequent finding.
Should I stop using AI coding tools?
No. They're the fastest way to validate an idea ever built. Use them to prototype; bring in engineering when real users, money, or data are about to be involved.
Will you work with the code I already have, or start over?
We audit first and keep whatever is sound. The AI-built version is at minimum an excellent specification, and often much of it is salvageable.