How to tell whether a vibe-coded app should be repaired or replaced

The short answer

Repair when the app has one clear structure, its core journey mostly works and its data is stored somewhere sound. Replace — or rebuild a smaller version — when nobody can say which code actually runs, the data model fights every change, or the main journey has never worked end to end. Those facts usually make the choice much clearer; the expensive mistake is choosing before they are known.

A rebuild quote given without reading the source is a guess. So is “it’s almost done”. Ask for the evidence behind either.

Six questions that decide it

1. Is there one application, or several? AI tools can leave an earlier prototype beside a newer version — the inspection described below found exactly that. If the repository holds two apps with different entry points, the first job is finding which one the build starts. A feature that exists only in the unused copy does not count.
2. Does the core journey work end to end? Pick the one thing a user must be able to do — book, pay, generate, save — and try it on the deployed app. If it works with rough edges, that favours repair. If it has never completed once, that favours replacing at least that part.
3. Is the data stored somewhere you control? Real users and real records change the calculation: they have to be migrated, not just rebuilt. Check where the data lives, who owns the account and whether access rules exist at all.
4. Are secrets and trust boundaries in the right place? Keys in browser code, an open paid API or missing access rules are serious but usually repairable. They are a reason to fix the boundary first, not on their own a reason to start again.
5. Does each change break something else? If every prompt to fix one feature breaks another, the structure is fighting you. That is the strongest practical signal for replacing the affected part.
6. Is the stack one you can keep supporting? A mainstream framework and hosting setup can be maintained by most developers. An unusual combination chosen by a tool and understood by nobody is a long-term cost, even when it works today.

The option most people skip: a smaller product

The choice is rarely only repair or replace. Often the right answer is to keep the parts that work, cut the features that were never finished, and ship a narrower version that does one job reliably. It is often cheaper than either extreme, though not always once salvage and integration work are counted, and it gives you real usage to decide the rest on.

A useful test: if you removed every feature that does not work end to end today, would what is left be worth shipping? If yes, repair that and stop there. If no, the app was a demo, and the next build should start from what the demo taught you.

What the evidence should look like

Ask whoever assesses the app — including Wilde Digital — to separate three kinds of finding:

• Observed: seen failing or working, with the steps to reproduce it.
• Source-supported: visible in the code or configuration, but not yet run.
• Unverified: claimed by a tool, a previous developer or a summary, and not yet checked.

The anonymized inspection described on the AI project rescue page is an example of the method. It found a second, unused prototype in the same repository, a speech feature that existed only in that prototype, and mobile packaging claims with no matching platform directory. None of those meant the app had to be replaced. Together they changed what “almost finished” meant, which is the point of looking before deciding.

What the decision costs

Wilde Digital separates the decision from the work. An inspection is $1,500 USD per agreed inspection and ends with a written recommendation to repair, reduce scope or replace, with the reasoning visible. Repair is quoted from $3,500 usd per agreed repair scope, for a defined group of changes. A replacement is quoted as a new build, not slipped into a repair.

Buying the inspection does not commit you to either. If the app turns out to need a deploy fix rather than a decision, why an AI-built app works in preview but breaks after deploy covers the five usual causes you can check yourself.