App rescue
Should I repair or rebuild my AI-built app?
Use a practical decision table to compare fixing an existing app, replacing one part and starting again without losing the work already done.
An app that has become hard to change does not automatically need a rebuild. First find out whether the problem is concentrated in one part, whether the important user journeys still work, and what the business must keep. A repair can be the fastest sensible route when the foundations are sound. A rebuild can be cheaper to maintain when the same flaw runs through the whole system. You need evidence before choosing either.
This guide is for someone who owns a web app built with an AI tool or inherited from another developer. The examples are illustrative; they are not client results.
Start with the journeys you cannot lose
Write down the two or three things a real user must be able to do, such as sign in, make a booking and pay. Try them on the live app with test accounts. Record what happens, where it fails and whether the data stays correct. A list of messy files tells you less than a broken customer journey.
Then identify the parts you can keep: the working design, the business rules, content, customer data, domain and accounts. Even if the code needs replacing, these can form a much better brief than starting with an empty page.
Compare three options
| What you find | Likely starting option | What to check before committing |
|---|---|---|
| The main journeys work, the code is accessible, and failures are limited to identifiable defects. | Repair the app. | Can you reproduce the defects, add tests around the important journeys and make changes without breaking unrelated features? |
| One area, such as sign-in or a payment handover, causes most of the failures. Other parts are usable. | Replace that part. | Can the replacement connect to the parts you keep, and can you move existing data safely? |
| Access rules, data model and deployment are tangled throughout the app, and every change creates another failure. | Price a wider rebuild. | What will it cost to migrate data, preserve live services and support users during the change? |
These are prompts, not a formula. A small app with sensitive records may need urgent access fixes even if most screens work. An untidy codebase might still serve its users well and need only a focused repair.
Compare the whole cost
Ask for a written scope for each plausible option. It should include diagnosis, the agreed changes, testing, data migration where needed, deployment, handover and any ongoing support. A cheap patch that leaves an unknown payment failure is not the same scope as a tested repair. Equally, a rebuild quote that ignores data migration is incomplete.
If the app is live, agree how users will keep working while changes are made. Where possible, inspect and test on a separate copy before touching production. Make sure you know who owns the repository, hosting, database and domain. Those details affect both the work and the eventual handover.
Make the decision from findings
An app health check is one way to get that evidence. It reviews one web app's code, database and hosting, records findings in priority order, and recommends repair, replacing a part or starting again. You can see the format in the illustrative report. The current health check is £495 for one code repository, one database project and its hosting; fixes are quoted separately, with the fee deducted from fixes booked within 30 days of the report. Larger apps are quoted before work starts.
Before asking anyone for a quote, prepare a short list of what the app does, the journeys that fail, the accounts you control and the decision you need to make. Do not put passwords, secret keys or customer data in an initial enquiry. If you want help choosing a route, describe your app.
Put the thinking into practice
Make the next step clearer.
Explore how I can help with an app you’ve already built, or tell me what you have in mind.
Explore app rescue