We work in your timezone - UK / Europe / Canada / Gulf London Dublin Toronto Dubai
Home / Guides / Finish an abandoned app
Guide · App rescue

How to finish an abandoned app — salvage or start over?

Half-built apps are more common than finished ones. A freelancer vanishes, an agency folds, a budget runs dry — and you're left with a codebase you can't read and a decision you can't dodge: pay someone to finish it, or write it off and rebuild. This guide gives you the framework to decide: the three questions that determine salvageability, a 30-minute smoke test you can run yourself, the checklist a professional audit works through, and the honest economics of rescue versus rebuild.

In short

Three questions decide whether an abandoned app is worth finishing: do you have the code, does it run, and is the architecture sane? Yes to all three and finishing is almost always the cheapest path. Yes to the first two but the code is a mess, and a refactor-and-finish sits in the middle. No to any of them — no repository, nothing boots, or the wrong foundation entirely — and a rebuild is usually the honest answer, and frequently the cheaper one. Everything below is how to answer those three questions with evidence instead of hope.

The framework

The three questions that decide everything

1 · Do you have the code?

Not screenshots, not a live URL, not "it's on his laptop" — the actual source code, in a repository or archive you control. Without it there is nothing to finish; a deployed app without its source is a photograph of a building, not the building. Recovering the code is always job one, and it is worth real effort: a written request citing your contract, settling a disputed invoice, even paying for a handover often costs far less than a rebuild.

2 · Does it run?

Code that boots on a fresh machine is a going concern; code that only ever ran on the departed developer's laptop may effectively not exist. If a new engineer can install the dependencies and start the app locally, every remaining problem is a known, fixable quantity. If nobody can get it running, the cost of finishing it is unknowable until someone does — and sometimes it never does.

3 · Is the architecture sane?

This is the question only a professional can answer, and the one that decides cost. Sane doesn't mean elegant — it means a recognisable structure, a maintained framework, a data model that matches the business, and no decisions that have to be undone before work can continue. Messy-but-sane code can be finished. Code built on the wrong foundation has to be fought, commit by commit, and that fight is what makes "finishing" cost more than starting over.

Do this first

The 30-minute smoke test a non-developer can run

Before you pay anyone for anything, you can gather real evidence yourself. None of these steps requires you to read code — they test whether the project is a functioning artefact or a pile of files. Work through them in order and write down where you get stuck; that note alone will make any professional audit faster and cheaper.

An honest caveat: if these steps feel alien — you don't know what a terminal is, or the instructions below read like another language — don't force it. Fumbling through commands you don't understand proves nothing either way, and one wrong move against a live database can make things worse. Pay for a professional audit instead: it's a small fixed cost, and a wrong salvage-or-rebuild decision is an expensive one to get cheap advice on.

The four checks
  • Does the repo clone? Log in to the GitHub, GitLab or Bitbucket account and download the repository to your machine. If you can't — no access, no repo, or an empty one — stop here: recovery, not finishing, is your problem.
  • Does a README exist? Open the folder and look for a README file with setup instructions. Its presence signals a developer who expected someone else to run the project; its absence predicts everything else you'll find.
  • Do dependencies install? Follow the README's install step (commonly npm install, composer install or similar). A clean install is a strong health signal; a wall of errors and deprecation warnings is data too.
  • Does anything boot? Run the start command the README gives you. You're not testing features — you're testing whether a stranger's machine can bring the app to life at all.

Four passes means you very likely have a salvageable project. One or two failures means the audit below matters. Total failure at step one means skip ahead to the red flags section.

What the professionals check

The code-audit checklist behind a real quote

A proper takeover audit reads the code before promising anything about it. Whoever you hire, this is roughly what they should be checking — and if a provider offers to quote your rescue without doing most of this list, that quote is fiction.

  • Build and boot: does the project build from a clean checkout and run end to end, including any background jobs and integrations?
  • Dependency health: how out of date are the packages, and do the installers or security scanners raise known-vulnerability warnings that must be fixed before launch?
  • Test coverage: are there automated tests, do they pass, and do they cover the parts of the app that would be dangerous to change blind?
  • Hardcoded secrets: are API keys, database passwords or payment credentials written directly into the code? Each one is both a security incident and a rework item.
  • Framework version: is the framework current, merely behind, or end-of-life? An unsupported major version can quietly turn a "finish" into a migration project.
  • Data model sanity: does the database schema actually match the business — or will core features fight the way the data is shaped forever?
  • Licence check: are the open-source licences in the dependency tree compatible with a commercial product, and is there any copied code with no licence at all?

The output you should expect isn't a score — it's a decision: finish, refactor-and-finish, or rebuild, with a costed scope attached. That's exactly what a Meridianstacks app rescue audit produces, and the audit is useful even if you take the plan elsewhere.

The economics

Rescue vs rebuild — where the money actually goes

Sunk cost is the enemy here. What you've already spent is gone either way; the only question is which path forward is cheaper from today. As a rule of thumb:

What the audit findsVerdictWhat it costs
Code runs, architecture is saneFinish itThe cheapest path — a code takeover with completion of a defined scope, typically £8,000–£12,000 via our app rescue service
Code runs, but it's a messRefactor and finishThe middle path — takeover plus targeted rework of the worst areas before new features; scoped from the audit, usually landing between the takeover band and a rebuild
Doesn't run, no code, or wrong foundationRebuildThe honest reset — priced as a normal build (a validation-stage web MVP is £12,000–£20,000). Often cheaper than fighting a broken base, because every pound buys progress instead of archaeology

Prices published from our Open Price Book (v1.0 · July 2026 · next review October 2026). All prices exclude VAT.

The counterintuitive part: a rebuild is frequently less expensive than a rescue of bad code. Engineers untangling someone else's broken decisions move slowly and unpredictably; engineers building on a clean base move fast and to a schedule. Full build bands for every project type are in the Open Price Book.

Know when to fold

Red flags that mean start over

Some projects should not be rescued, and the kindest thing an honest engineer can tell you is to stop paying for the old one. Any single flag on this list is survivable; two or more together almost always mean the rebuild column is your answer.

If that's where you land, don't treat it as a total loss. The abandoned build usually leaves behind the most expensive part of any software project: a tested understanding of what the product actually needs to do. Founders who rebuild after a failed first attempt tend to scope tighter, choose better, and ship faster — because this time they know.

The walk-away list
  • No repository at all — the code exists only on the developer's machine or a deployed server you can't access
  • Hardcoded credentials everywhere — secrets scattered through the source mean a security rework before feature work can even begin
  • Abandoned framework versions — the platform it's built on is end-of-life, so "finishing" secretly includes a migration
  • No way to run it locally — if nobody can boot the app on a fresh machine after honest effort, every estimate about it is a guess
Keep reading

Related guides

Taking over another developer's code

What a professional handover looks like when the previous developer is still reachable — access transfer, knowledge capture and a clean break.

My freelancer abandoned my project — now what?

The first-48-hours playbook: securing accounts, recovering code and money, and deciding who finishes the build.

Questions & answers

Finishing an abandoned app — FAQ

Can an abandoned app project be saved?
Usually, yes — if you have the source code, it runs, and the architecture is sound. Those three questions decide almost everything. A project that passes all three can normally be finished by a new team for far less than a rebuild; a project that fails on the code or the foundations is usually better restarted, which is often cheaper than paying engineers to fight a broken base.
What if I don't have the source code at all?
First, ask for it in writing — depending on your contract you may be legally entitled to it, and many developers hand it over once payment disputes are settled. If the code is genuinely unrecoverable, no one can 'finish' the app: a rebuild is the only route. The consolation is that the first attempt taught you exactly what to build, so version two is usually faster and better scoped than version one.
How much does it cost to finish a half-built app?
It depends on what the audit finds. Code takeovers — where the existing codebase is sound enough to finish — typically run £8,000–£12,000 ex VAT at Meridianstacks, covering the audit, stabilisation and completion of a defined scope. If the project needs a rebuild, our standard build bands apply instead: a validation-stage web MVP, for example, is £12,000–£20,000 in our Open Price Book. Anyone who quotes you a firm figure before reading the code is guessing.
Is it cheaper to finish an existing app or rebuild it from scratch?
Finishing is cheaper only when the code runs and the architecture is sane. If the codebase is broken, undocumented or built on abandoned framework versions, a rebuild is often the cheaper option over any horizon longer than a few months — you stop paying engineers to wrestle the old code and start paying them to ship features. A short professional audit is the cheapest way to find out which side of that line you are on.
My freelancer disappeared mid-project — what should I do first?
Secure your assets before anything else: get admin access to the repository, hosting, domain and app store accounts, and export whatever code and documentation exist. Only then think about who finishes the build. If the work happened on a marketplace such as Upwork or Fiverr, use its dispute process for the money — but treat code recovery as the priority, because it decides whether the project can be rescued at all.

Want the salvage-or-rebuild answer for your project?

Send us the repository and we'll run the full audit — build, dependencies, secrets, data model, licences — and give you a straight verdict with a costed plan, in your business hours. If the honest answer is "rebuild", we'll tell you that too.

Start an app rescue →