Projects get abandoned for ordinary reasons more often than dramatic ones. A freelancer takes a full-time job. A small agency loses its one developer who knew your project. Someone underquoted, ran out of money halfway, and quietly stopped. Occasionally it's worse than that, but usually the code isn't sabotaged. It's just unfinished, undocumented, and sitting somewhere you may or may not have access to.
This guide is different from rescuing a legacy application. A legacy app is old but working; the problem is that it's fragile. An unfinished project is the opposite: it may be built on perfectly modern technology, but it has never actually worked end to end, and the person who knew how close it really was has gone. That changes what you do first.
The first 48 hours: secure what you own
Before you think about code quality or deadlines, make sure you control the things the project runs on. Every one of these is far easier to sort out now, while the old developer is merely slow to reply, than later if the relationship turns sour.
- The source code. Get the full repository, with its history, into a GitHub, GitLab or Bitbucket account you own. A zip file of the latest code is better than nothing, but the history shows what changed recently and what was abandoned halfway.
- Hosting and cloud accounts. Azure, AWS, a VPS, Netlify, whatever runs the app. If it's in the developer's personal account, ask for it to be transferred, or at least for you to be added as an owner.
- The domain and DNS. Whoever controls the DNS controls where your users end up. Make sure the registrar account is yours.
- The database. Take a backup now, and store it somewhere you control. If there's real customer data in it, this is the most valuable thing in the whole project.
- Third-party services. Payment gateway, email provider, SMS, maps, any supplier APIs, app store and Shopify Partner accounts. Make a list of every service the app talks to and who owns each login.
Once you have access, change the passwords and rotate the API keys, especially for payments and email. That isn't an accusation. It's simply good practice whenever someone with production access leaves, and it closes the door on any accidental damage.
Don't start by adding features
The natural instinct is to find a new developer and say "finish the last 20%." Resist it. Nobody, including the previous developer, actually knows whether it's 20%. "Done" in an abandoned project usually means "a screen exists," not "it works, it's tested, and it's deployed." Asking someone to add features to code they don't understand yet is how the second developer ends up abandoning it too.
The first piece of work should be a short, fixed-scope audit: a few days to a week in which a new developer reads the code, gets it running, and tells you plainly what state it's in. It's the cheapest decision you'll make in the whole recovery, because everything else is estimated from it.
What a takeover audit actually checks
When I take over someone else's half-finished project, these are the questions I need answered before I'll estimate anything. You can use the list to judge whether whoever you hire is doing a real audit or just skimming.
1. Does it build, and does it run?
The most basic test, and the one that fails surprisingly often. Can a fresh machine pull the repository, restore its dependencies and start the app? Missing configuration files, secrets that only lived on the old developer's laptop, and packages pinned to versions that no longer download are all common. Until it runs locally, nothing else can be trusted.
2. Can it be deployed, and by whom?
Is there a repeatable deployment, such as a pipeline or at least a written process, or did the old developer copy files to a server by hand? If only one person ever knew how to release it, that knowledge has to be rebuilt before anything new ships.
3. Is "done" really done?
This is where the gap between what you were told and what exists shows up. I go through every feature that was reported as finished and check it end to end:
| What you were told | What to check |
|---|---|
| "Payments are done" | Does it work with live keys, handle failed and refunded payments, and record the result in the database, or only the happy path in test mode? |
| "Login works" | Password reset, email verification, roles and permissions, and whether passwords are stored properly hashed. |
| "The admin panel is built" | Do the screens save real data, or are they layouts wired to sample values? |
| "It's integrated with the API" | Is it a real connection with error handling and retries, or one successful call made against a sandbox? |
| "It's basically finished" | Is there a production environment at all, with backups, logging and HTTPS, or has it only ever run on a laptop? |
4. Where are the secrets and the risks?
Passwords and API keys committed into the code are common in rushed projects, and once they're in the repository history they have to be treated as exposed and replaced. I also look for the obvious security gaps that unfinished projects tend to have: no input validation, admin pages without proper authorisation checks, and outdated packages with known vulnerabilities.
5. Is the data model sound?
Code can be refactored a piece at a time. A database designed around the wrong idea of the business is much harder to fix once real data lives in it. If orders can't have more than one product, or a customer can only ever have one address, it's far better to find out now than after launch. For most projects this is fine. When it isn't, it's usually the deciding factor in the next question.
6. Is the stack something people can maintain?
Mainstream frameworks such as ASP.NET Core, React, Node or Laravel can be picked up by plenty of developers. A home-made framework, an abandoned library at the core, or an unusual combination chosen because the old developer liked it means you'll be dependent on a small pool of people forever. That's a cost worth knowing before you invest more in it.
Finish, fix or rebuild?
The audit should end with a clear recommendation. In my experience it lands in one of three places:
| Verdict | When it's the right call |
|---|---|
| Finish it | It builds and runs, the structure is reasonable, and the gaps are missing features rather than broken foundations. The most common outcome. |
| Fix, then finish | The foundations are mostly right but some parts are unsafe or unreliable, such as payments, security or deployment. Those get repaired before new work goes on top. |
| Rebuild | It won't build or run, the data model is wrong for the business, or the stack is genuinely unmaintainable. Even then, the designs, the requirements and any working pieces are usually reusable. |
Be cautious of a new developer who recommends rebuilding before they've read the code. Sometimes it's honest. Sometimes it's because writing new code is more pleasant than understanding someone else's. A rebuild restarts the clock on a project that's already late and throws away business rules someone already spent your money working out. It should be a conclusion from the audit, never the opening position.
"It's 80% done" is a guess. An audit replaces the guess with a list, and a list is something you can actually budget.
What it realistically costs
There are two separate costs, and they should be quoted separately. The audit is a fixed piece of work, usually around a week. I quote rescue work this way, with the audit first, at my published day rate. Finishing the project is then estimated from what the audit found, feature by feature, rather than from what anyone remembers being promised.
Expect the finishing estimate to be larger than "the remaining 20%" suggested. That isn't the new developer padding the quote. It's the hidden work every abandoned project carries: getting it deployable, fixing what was reported as done but isn't, and writing the documentation that should have existed. If someone offers a fixed price to finish your project without looking at the code first, they're either guessing or planning to cut the same corners that caused the problem.
How to make sure it never happens again
Most of the pain in an abandoned project comes from a few setup decisions made on day one. On your next project, or the rest of this one:
- Own every account. The repository, the cloud account, the domain and every third-party service should be in your name, with the developer invited as a collaborator. When they leave, you remove their access, and nothing moves.
- Pay for working software, not progress reports. Tie payments to features deployed to an environment you can click through yourself, and split the project into phases so no single payment covers more than a few weeks of work.
- Insist on a handover note at each milestone. One page covering how to run it, how to deploy it, and what's unfinished. It takes an hour to write and saves weeks if someone new has to pick it up.
- Watch for silence early. Slow replies and vague updates in week three are the warning sign. Ask to see the work running, not described.
This is how I set up every project I take on: the code lives in the client's repository and deploys to the client's own cloud account from the first commit, so nothing ever depends on a login only I have. It isn't about expecting to disappear. It means the client is never in the position this article is about.
Unfinished project FAQs
Can a new developer continue someone else's unfinished code?
Should I rebuild from scratch instead of finishing the existing project?
How much does it cost to take over an unfinished project?
What if my previous developer won't hand over the source code?
How do I stop this happening on my next project?
I build and run a live travel reservation platform connected to four GDS / supplier integrations, and I've built admin platforms for enterprise teams. I write about the problems I actually solve for clients.
Inherited a half-finished project?
I take over stalled and unfinished applications, especially .NET backends, Shopify apps and booking systems. It starts with a fixed audit, then an honest recommendation to finish, fix or rebuild. Tell me what you've got and what access you have.
Start a project →