Software project rescue: how to take over a project your developer abandoned

To rescue a software project your developer abandoned, work in this order: secure access and backups in the first days, gather everything that was produced, have the code assessed, decide whether to finish, stabilize or rebuild, and only then choose who takes over and put it in writing. Code ownership matters from day one, but the answer lives in your contract, case by case, not in the invoices you paid.

This article covers the emergency itself: the developer has gone silent, the agency has closed, or what was delivered does not work. For the detailed technical review, read our guide to auditing an existing application before a takeover. To make sure it never happens again, our vendor lock-in exit plan explains what to put in the contract.

The situations we see

Projects do not stall in the same way, and the right response depends on how yours did.

• The vanished freelancer: no replies, no commits for weeks. The most common case, and usually the most urgent on the access side.
• The agency that closes or goes into insolvency: your contact becomes an administrator, receiver or trustee.
• The breakup: a dispute over scope, budget or quality. The vendor still exists, but the relationship is over.
• The "finished" project that does not work: delivered and paid for, but unstable, slow or incomplete, and nobody fixes it anymore.
• The internal departure: the in-house developer or technical co-founder who carried everything has left. Less of a legal problem, just as much of a practical one.

A few signs often come before the silence: delivery dates that slip without explanation, demos replaced by screenshots, reluctance to give you access to the repository, and increasingly pressing requests for upfront payment. If you recognize several, apply the next section now rather than waiting.

The first days: secure what can disappear

An abandoned project degrades fast, often quietly. Before looking for a new team, lock down what you could lose.

Inventory every account

List every service the application depends on and, for each, whose name it is registered in, who holds the credentials and what pays for it:

• the domain name and DNS settings;
• hosting (server, cloud provider, platform) and the database;
• the code repository (GitHub, GitLab or other);
• Apple and Google developer accounts for a mobile app;
• third-party services: email delivery, payments, maps, file storage, analytics;
• email and admin accounts for the application itself.

A service charged to the personal card of a freelancer who no longer answers can stop at the next billing date. An expired domain can be registered by someone else.

Take a full backup

Without waiting, get a copy of the database, files uploaded by users and the code as it runs in production. If you have admin access to hosting, do it yourself; if not, request it in writing.

Keep a written record

Note dates, keep messages, make requests in writing. That record helps if the situation turns into a dispute, and it helps your lawyer advise you.

Gather what was produced

Once access is secured, collect everything the project produced, not just the code:

• the full source code, with version history if possible;
• designs and prototypes, even unfinished;
• the specification, meeting notes and messages that explain decisions;
• credentials and secrets (API keys, service passwords), which you will need to rotate anyway;
• deployment steps, or at least a description of how the app goes live;
• known bugs and unfinished features.

Code alone is not enough. A new team that does not know how the app is deployed, or why a business rule exists, works in the dark.

Who owns the code?

Everyone asks this, and it is where caution matters most. A few general pointers, which do not replace legal advice in your own jurisdiction:

• code written by an employee as part of their job generally belongs to the employer in most countries;
• code written by an outside contractor generally stays with its author unless a written agreement assigns the rights to you. In the United States, the Copyright Office's Circular 30 on works made for hire explains why commissioned work does not automatically become the client's;
• paying invoices is usually not enough, on its own, to transfer ownership.

In practice, rights are defined case by case in the contract. Reread the contract, signed quotes, the vendor's terms and any amendments. Our article on who owns custom software source code walks through the common scenarios. If the vendor refuses to hand over the code or disputes your rights, talk to a lawyer before anyone touches it: a new team should not build on code you are not entitled to use.

If the vendor is insolvent, contact the administrator, receiver or trustee appointed in the proceedings. Deadlines to file claims can be short, so get advice without delay.

The assessment: what can be reused

Before deciding anything, get what exists assessed. The goal is not to judge the previous developer, but to answer three questions:

1. Is the code complete and deployable? Can the app be rebuilt from the repository, on a fresh environment, without the previous developer's help?
2. Are the foundations sound? Architecture, data model, security, up-to-date dependencies.
3. How far is it from what you need? What works, what is missing, what works badly.

The first test is the most telling: if a new team cannot redeploy the app from the code you were given, it already knows the rescue will be long. The full checklist (code, dependencies, security, data, hosting, documentation) is in our guide to auditing an application before a takeover.

Finish, stabilize or rebuild

The assessment leads to one of four decisions.

Two traps lurk here.

Sunk cost. "We have already paid for 60%" is not a technical argument. The only useful question is what it costs from here to reach reliable software, in each scenario.

Rewrite by reflex. A team that proposes rewriting everything before looking at the code may mostly want to work in its own stack. Conversely, fragile code that you keep patching often ends up costing more than a rebuild. Our article on technical debt for business owners helps you read that diagnosis.

Either way, what you learned is not lost: designs, business rules, test data and feedback from early users speed up whatever comes next. If the decision leans towards a rebuild, or your needs have moved on, the safest step is to see the project again before reinvesting: a free visual prototype, presented over video within 5 working days, can start from what already exists (designs, live screens, specification). Our article on prototypes, MVPs and proofs of concept explains what that first step can and cannot tell you.

If the previous developer resurfaces

It happens more often than you would think: the freelancer was ill, or overloaded, and comes back a few weeks later. Do not simply pick up where you left off. Use the moment to organize a proper handover: a walkthrough of the code and the deployment, a written list of what is finished and what is not, accounts and repository transferred to your company, and a few days of overlap with the new team if you have decided to move on. A handover done in good faith saves the new team weeks of guesswork, and it costs far less than a dispute.

Choosing the team that takes over

Taking over someone else's code is a specific skill. Questions to ask:

• Do they insist on an assessment before quoting? A fixed price without seeing the code is either reckless or padded to cover the unknown.
• Do they know the technology in place? Or do they push to migrate everything to theirs straight away?
• Are they clear about what they guarantee? A new team takes responsibility for what it fixes and builds, not for existing code it did not write. That is normal, as long as the boundary is written down.
• Will they make the project independent? Repository and accounts in your company's name, documentation, a repeatable deployment: the goal is never to depend on a single person again.
• How are they paid? A rescue can be done at a fixed price, stage by stage (assessment, stabilization, new features), which caps your risk. Our comparison of fixed price vs time and materials explains the difference.

Clauses not to forget this time

A rescue is the right moment to write down what the first contract missed:

• accounts, repository, domain and hosting in your company's name;
• code and documentation handed over at every milestone, not only at the end;
• rights to the code defined case by case in the contract, in plain words;
• an exit clause that describes how you leave, before you need it.

A typical rescue timeline

Every project differs, but the sequence is almost always the same:

1. Secure: access, backups, account transfers.
2. Assess: test redeployment, review, written report.
3. Decide: finish, stabilize, rebuild or rescope.
4. Stabilize: blocking bugs, security updates, tests on critical workflows.
5. Resume new features in small, visible releases.

Each stage produces something you can judge before funding the next. That is the best protection against a second abandonment.

Where to start

Start with the account inventory, today, before anything else. The rest of the list (backup, gathering the deliverables, assessment) follows in order, without waiting until you have chosen a new team.