You built an app with AI — Lovable, Replit, Bolt, a long weekend with Claude — and it mostly works. Now it's breaking in ways you can't fix by prompting harder. This is the rescue playbook we use: the 6-step path from AI prototype to production software, the refactor-vs-rebuild decision, and what it honestly costs.
You built an app with AI. Maybe it was a weekend with Lovable, a few evenings in Replit, a Bolt project that got further than you expected, or one long conversation with Claude that ended in working code. It does most of what you wanted — and now it's breaking in ways you can't fix by prompting harder. Before anything else: you didn't do anything wrong.You did the smart thing. You validated an idea for almost nothing, and you're now holding a working prototype that proves exactly what your software needs to do.
You're also not alone at this wall. Our DataForSEO AI-search data (June 2026) shows the question “can AI build an app” being asked roughly 117 times a month inside AI assistants themselves, and vibe-coding queries inside those assistants are up 151% year over year. A wave of people built software this way, and a predictable share are hitting the same wall at the same point: the prototype works, the tenth change breaks the third feature, and the AI keeps apologizing while making it worse.
This article is the playbook we use when these apps land on our desk: what to do in the first hour, the six-step path from AI prototype to production software, the refactor-vs-rebuild decision, and what a rescue honestly costs.
My AI-built app is breaking — what do I do first?
Stop prompting new changes, export your code and data, and rotate your API keys — in that order. The instinct when an AI-built app misbehaves is to open the chat and describe the bug, because that's how every other problem got solved. But by the time an app is breaking in ways prompting can't fix, the underlying architecture has usually degraded: each prompt patched one spot without understanding the whole, and the patches are now fighting each other. Every additional “fix this” has a real chance of quietly breaking two things you weren't looking at. On a degraded codebase, prompting harder is how a limping app becomes a dead one.
Export comes next — and it comes before diagnosis, because it isn't guaranteed. Some platforms hand you the full codebase in a click; others limit export by plan tier or keep parts of the stack proprietary. Get the code out, and get the data out (a database dump or a CSV of every table), while everything still works well enough to do it. If the platform ever locks you out, has an outage, or changes its pricing, that export is the difference between a recovery project and a rewrite from memory.
Then rotate every API key and secret that has ever touched the project, and check the mundane suspects: the provider's status page, your usage limits and billing (an exhausted quota looks exactly like a mysterious outage), and any credentials that may have expired. One hard line: if the breakage involves customer data or payments, treat it as a security event, not a bug — get an engineer to look before your users find it for you.
What's the playbook for getting a vibe-coded app production-ready?
Six steps, in this order: export, security audit, data-model assessment, the refactor-or-rebuild decision, hardening, and real operations. This is the sequence we run when a vibe-coded app lands on our desk, and the order matters — each step protects the ones after it:
- Export and secure your code and data. Covered above, and worth restating as step one: get the code and data out of the platform and rotate every secret before touching anything else. Nothing later in the playbook is safe to do on an app you could lose access to tomorrow, or one that's still leaking the keys you're about to rely on.
- Run a security and secrets audit. Before improving the app, find out what it's exposing right now: API keys sitting in frontend code, authentication that exists only in the UI, database rules that let anyone read any table, user input that flows unvalidated into queries. These are the failures that turn an embarrassing bug into a catastrophic one, and AI-generated apps ship them at a startling rate — we break down all six recurring holes, with the fix for each, in vibe coding security risks.
- Assess the data model. How the app stores and relates its data decides everything built above it. A sound structure — sensible tables, clear relationships, no duplicated state — can be hardened in place. A broken one poisons every feature on top of it, and no amount of surface fixing repairs that. This single assessment usually settles the next step on its own.
- Decide: refactor or rebuild. With the audit and the data-model findings in hand, the call gets made deliberately instead of by momentum. Localized problems — exposed secrets, missing auth, a few broken flows — get fixed in place. Degraded architecture gets rebuilt on a clean foundation, with your prototype serving as the specification. The full decision logic is in the next section.
- Harden the core flows. Server-side authentication on every route, validation on every input, error handling that fails loudly instead of silently, and automated tests on the flows that touch money and data — signup, checkout, anything that writes a record someone will rely on. Not every corner of the app needs this rigor; the flows where a mistake costs real money or real trust absolutely do.
- Set up real deployment, monitoring, and maintenance. Production software needs a deployment pipeline instead of live edits, automated backups someone has actually rehearsed restoring, and logging and monitoring so you hear about failures before customers do — plus a named owner for the 2am failure. This unglamorous step is most of the difference between software that works today and software that still works next year.
The steps are boring on purpose. The exciting part — the idea, the features, the design — you already did. This is the part that makes it durable.
Should you refactor or rebuild?
Refactor when the problems are localized; rebuild when every change breaks something unrelated. That's the compressed version, and it's worth expanding, because this fork in the road sets the budget for everything after it. The signals point clearly in most cases:
- Refactor when: the data model is sound, the platform lets you export and own the code, the audit findings are countable and specific (secrets, auth, a handful of broken flows), and the app's scope isn't about to grow dramatically.
- Rebuild when: the architecture has degraded across dozens of prompts, fixes routinely break unrelated features, the platform locks your code in, or the problems are woven through everything rather than sitting in identifiable places.
- The tiebreaker: price both paths honestly. If fixing piecemeal costs more than starting clean — a common outcome once a codebase is fighting itself — rebuild.
A useful rule of thumb: if every new change breaks something unrelated, the architecture is already gone. At that point you're not deciding whether to rebuild — you're deciding how long to postpone it, and each postponement adds features that will have to be ported later.
Here's the reframe that matters more than the decision itself: your prototype is the spec. The most expensive part of custom software was never the code — it's figuring out what the software should actually do, a discovery process that normally burns weeks of meetings, mockups, and revision cycles. You already did that work, interactively, against a living artifact. A rebuild that starts from a working prototype skips the most failure-prone phase of development entirely. What a clean, engineered build involves from there — data modeling, integrations, the deliberately unglamorous parts — is laid out in what is custom application development.
What does production-ready actually mean?
Production-ready means the app keeps working when things go wrong — not that the demo looks right. A demo proves the idea works; production-readiness proves it keeps working when a user does something strange, a third-party service goes down, or an attacker shows up. Concretely, it's a checklist:
- Authentication enforced server-side. Hiding a page in the interface protects nothing; every route and API endpoint verifies who's asking.
- Secrets out of the code. API keys and credentials live in server-side configuration, never in anything a browser can download.
- Input validated on the server. Every field a user can touch gets checked and sanitized before it reaches your database.
- Errors handled and logged. Failures produce useful records instead of silent wrong answers or blank screens.
- Data backed up — and restorable. Automated backups exist, and someone has actually rehearsed restoring one.
- A real deployment pipeline. Changes are tested and rolled out deliberately, and can be rolled back — no editing the live app.
- Monitoring in place. You learn the app is down from an alert, not from a customer's email.
- Code a second engineer can understand. If the only thing that ever understood the system was a chat window, the system has no owner.
Most vibe-coded apps arrive with roughly zero of these eight. That's not a criticism — builders optimize for the demo, and the demo doesn't need backups. But it explains why “it mostly works” and “it's production-ready” can be so far apart while looking identical from the outside.
How much does a rescue cost?
A hardening pass commonly runs $5,000–$20,000; a partial rebuild $15,000–$50,000 — a fraction of a from-scratch build because your prototype already answered the hardest question. For comparison, building a comparable custom application from zero typically lands at $50,000–$150,000 once real integrations are involved; the full breakdown of what drives those numbers is in how much does custom software cost in 2026.
The discount isn't generosity; it's arithmetic. Requirements discovery — the meetings, mockups, and revisions needed to figure out what to build — consumes a large share of any project budget, and your prototype already settled it. What you're buying in a rescue is the engineering: security, data structure, reliability, and operations. Where a specific project lands inside those ranges comes down to what the audit finds — how much is genuinely broken — and how much of the app touches money, customer data, or outside systems.
One caution as you shop the work around: this engagement deserves the same vetting as any custom project. Ask who will actually do the work, look for evidence the team has rescued AI-generated codebases before, and get the refactor-vs-rebuild recommendation in writing with the reasoning attached — a shop that only ever recommends the full rebuild is selling, not assessing. Our complete vetting checklist is in how to choose a custom software development company.
Bring us the app AI built you
Tell us what you built — Lovable, Replit, Bolt, a long Claude session, whatever it was — and where it's struggling, and we'll send back a free engineering read: refactor it, rebuild it, or honestly, leave it alone. No judgment about how it was built; a working prototype is a head start, not a confession. If it's a fit, you get a written estimate with the reasoning attached.
Prefer to talk it through? Call us directly at (909) 662-4058 . No intake form required.
Frequently asked questions
Can a developer fix my vibe-coded app?
Usually, yes — and it's become a common engagement. The first step is an assessment: an engineer reviews the generated codebase for security issues, data-model problems, and architectural damage from iterative prompting. From there the app is either hardened in place (refactor) or rebuilt on a clean foundation while keeping your prototype as the specification. Either way, the work you did isn't wasted — a working prototype is the best requirements document a developer can get.
Should I rebuild or refactor an AI-built app?
Refactor when the data model is sound, the codebase is exportable, and the problems are localized (secrets, auth, a few broken flows). Rebuild when the architecture has degraded across many prompts, the platform locks your code in, or fixing piecemeal costs more than starting clean. A useful rule: if every new change breaks something unrelated, the architecture is already gone — rebuild on a clean foundation and port the features.
How much does it cost to make an AI prototype production-ready?
A hardening pass on a fundamentally sound prototype (secrets, auth, validation, deployment) commonly runs $5,000–$20,000. A partial rebuild — keeping the design and data concepts, rebuilding the foundation — typically runs $15,000–$50,000. That's meaningfully cheaper than the $50,000–$150,000 a comparable from-scratch build costs, because your prototype already answered the most expensive question: what should this software actually do?
My Lovable / Replit / Bolt app stopped working — what should I do first?
Stop prompting new changes — iterative fixes on a degraded codebase usually break more than they repair. Export your code and data if the platform allows it (do this before anything else). Then check the basics: provider status pages, API usage limits and billing, and any keys that may have expired or been rotated. If the failure involves customer data or payments, treat it as a security event and get an engineer to look before users do.
What does production-ready actually mean?
Production-ready means the app survives contact with reality: authentication enforced server-side, secrets out of the code, input validated, errors handled and logged, data backed up, a real deployment pipeline instead of editing live, monitoring so you hear about failures before customers do, and code a second engineer can understand. A demo proves the idea works; production-readiness proves it keeps working when things go wrong.