The short answer
Nobody can tell you whether a half-finished project is worth saving without looking at the code. Anyone who quotes before looking is guessing, and the guess will be wrong in the direction that wins them the work.
If your developer has just gone quiet, start with what to do about that instead. This page assumes you already have, or can get, the code.
The five questions
1. Can you get the code and the accounts? If not, this is a legal question before it is a technical one, and the answer may make the rest moot.
2. Does it run? Not "does it demo". Can someone check it out, install the dependencies, and run it. A project nobody can build is closer to zero than to eighty percent.
3. How much of it is the boring 20%? Auth edge cases, error handling, payment states, store compliance. The visible screens are the easy part. If only the screens exist, less has been done than it looks.
4. Is it comprehensible? Undocumented code written by someone unreachable is expensive to understand. Sometimes more expensive than replacing.
5. What would a rebuild cost? Asked honestly, as a real comparison, not rhetorically.
Why "80% done" is usually wrong
What is usually worth keeping
Even when the code is not salvageable, other things are.
- The designOften the most reusable asset, and it saves real time.
- The decisionsYou now know what the product should do, which is what day one usually costs.
- The accounts and listingsIf a store listing exists, keep it.
- The knowledge of what went wrongWhich should change how you structure the next deal.
Common questions
Is it cheaper to finish it or start again?
More often start again than people expect. Understanding a large body of unfamiliar, undocumented, partly-working code can take longer than writing it properly from a clear scope.
What do I need before anyone can assess it?
The repository, the accounts, and any documentation. Without the code, nobody can give you an honest answer, and anyone who quotes without it is guessing.
What if it is 80% done?
It is almost never 80% done. The last 20% of a software project is where most of the difficulty lives: edge cases, error handling, store compliance, and performance. A project described as 80% done is often closer to half.