How to Take Over Software Your Developer Abandoned

To take over software your developer abandoned, follow six steps in this order: recover the accounts, make a full copy of the code and data, confirm you own the code, have it audited, stabilize production, and only then start building again. The order matters. Most takeovers that go wrong start with a new feature requested from the new team before anyone has checked that the application can even be redeployed.

We take over these projects regularly at Reflekt Lab. Here is the method we use, and what you can do yourself before calling anyone.

Signs your software has been abandoned

You are probably in this situation if one of these sounds familiar:

• the freelance developer stopped answering, or has been saying "next week" for two months;
• the agency closed, was acquired, or moved the team that knew your project onto other work;
• the relationship broke down over an unpaid invoice or a sign-off that never happened;
• your technical cofounder left, and nobody inside the company knows how to deploy;
• nobody is sure who pays for the hosting or where the backups are.

The application still works, which is what makes this deceptive. It will keep running until a certificate, a domain name or the credit card on the hosting account expires.

Step 1: recover the accounts

This is the urgent part. Before anything technical, find out who holds the keys. List every account and move it into your company's name, or at the very least add yourself as an administrator:

If the developer is reachable, ask for all of these transfers in writing, in a single email, and keep the reply. If they are not, registrars and hosts have ownership-change procedures that work with proof that the account was run for your company.

Step 2: make a full copy

As soon as you have access, copy everything before touching anything: the complete Git repository with its history, a database backup, the files users uploaded, and the server configuration. Store it in your own account, not with the next vendor.

That copy protects you against two real risks: the old developer shutting down the hosting, and a mistake during the takeover.

Step 3: confirm you own the code

This is the question we ask before we read a single line, because a takeover without the rights is legally fragile.

Paying for development does not, by itself, make you the owner. Under US copyright law, an independent contractor or agency owns the code they write unless a signed written agreement assigns it to you. Software is not one of the categories where a contractor's work can count as a "work made for hire", so the contract needs an explicit assignment of rights. Code written by your own employees as part of their job belongs to the company. Other countries have their own rules, and most of them also default to the author.

Re-read the contract, the signed proposal or the agency's terms. Three cases come up:

1. The contract assigns all rights to you: you can hand the code to another team.
2. The contract only grants a license to use it: you can run the software, not necessarily have a third party change it. You need to negotiate an assignment, which is often possible amicably.
3. There is no written contract: the situation is unclear. A technology lawyer will settle it faster than you can.

If the code was deposited with a software escrow agent, the escrow agreement usually releases it when the developer stops supporting the product. Check whether one exists.

Step 4: have the code audited

A source code audit answers one question: can this software be changed without breaking everything, and at what cost? It looks at the architecture, technical debt, security flaws, outdated dependencies, the presence of tests and how the application deploys.

The useful deliverable is not an overall grade. It is a list of what is sound, what can be taken over and what genuinely needs rewriting, with an estimate for each item. At Reflekt Lab the audit is a fixed $2,900 (€2,500) and takes two to five days. You can stop there and hand the rest to whoever you like.

Be wary of a vendor who prices a takeover without reading the code, and even more of one who proposes a full rewrite at the first meeting.

Step 5: stabilize before you build

This is the step everyone wants to skip, and the one that prevents the Monday-morning outage. Before the first new feature, the new team must be able to:

• rebuild and redeploy the application from the repository, without the old developer;
• restore a backup and confirm it actually works;
• run tests on the critical paths: checkout, invoicing, sign-in;
• get alerted when the application goes down, rather than hearing it from a customer.

Until those four are in place, every change is a gamble.

Step 6: resume development

Once production is stable, the takeover becomes an ordinary project. Put a maintenance agreement in place that covers fixes, security updates and a volume of changes. Make sure it lets you leave: accounts stay in your name, the code in your repository, and the documentation current. Otherwise you rebuild exactly the dependency that got you here.

Rewrite or take over?

Take over, almost always. A rewrite throws away work you already paid for, takes months before the first release, and rediscovers one by one the edge cases the old code already handled. It is justified for a specific component: a technology that is no longer maintained, a module nobody can test, a structural security flaw. The audit tells you which ones.

Apps generated with AI tools (Lovable, Bolt, Cursor, Replit) are a slightly different case: the code exists, but often nobody has ever read it. The method is the same, and the audit matters even more.

Further reading

The full offer, with prices and steps, is on our software project rescue page. The maintenance contract that follows a takeover is covered in software maintenance and support services. And if you are weighing a fresh start, custom software for small business gives the price ranges.