Your last developer disappeared. Now what?

It happens more than people think. You hired a freelancer or a small agency to build something. It worked for a while. Then they stopped responding. Maybe they moved on to other projects. Maybe they closed up shop. Maybe they just went quiet.

Now you're stuck with software that's running your business, and nobody left who knows how it works.

We've walked into this situation many times. Here's what to expect and what to do.

First: don't panic

The software is still running. It might have bugs. It might be slow. It might be missing features you need. But it's working, at least partly. That gives you time to plan instead of react.

The worst thing you can do right now is rush to hire the first person who says they can fix it. Take a breath. Assess what you have. Then make a decision.

Gather what you can

Before you talk to a new developer, collect everything you have related to the project:

Access credentials. Logins to the servers, databases, hosting accounts, and domain names. If your old developer set these up, you need to make sure you have the keys. If you don't, start reaching out to hosting companies to recover access. This is time-sensitive.

Source code. Do you have a copy of the code? Is it in a repository you can access? Or does it live on a server somewhere? If you don't have the source code, a new developer can still work with the running system, but it's harder and more expensive.

Any documentation. Specs, emails, notes, screenshots. Even a loose description of what the software was supposed to do is helpful. Most abandoned projects have little or no documentation, but check your email and old files. Anything helps.

A list of what's broken. Write down every problem you're aware of. What doesn't work? What works but barely? What feature were you waiting on that never got built? This gives a new team a starting point.

What a rescue team does first

When we take over an abandoned project, we don't start fixing things right away. We start by understanding what's there.

Code review. We read through the existing code to understand how it was built, what shape it's in, and where the risks are. This tells us whether the code is worth saving or whether it's better to rebuild certain parts.

System assessment. We look at the servers, the database, the security setup, and the hosting. Is the system safe? Is it backed up? Are there any urgent risks that need to be fixed right away?

Honest assessment. After the review, we give you a straight answer. Here's what's good. Here's what's bad. Here's what needs to be fixed now. Here's what can wait. And here's what it'll cost to get things to a stable, maintainable state.

Sometimes the answer is that the code is fine and just needs some care. Sometimes the answer is that parts of it should be rebuilt. Rarely, the answer is to start over. We tell you the truth, even when the truth isn't what you want to hear.

The most common problems we find

No backups. This is the scariest one. If the server fails and there's no backup, the data is gone. When we take over a project, setting up reliable backups is job one.

Security holes. Old software that hasn't been updated is a target. Outdated frameworks, unpatched libraries, and weak passwords are common. We fix the urgent ones immediately and build a plan for the rest.

Hard-coded shortcuts. Developers in a hurry take shortcuts. Passwords stored in plain text. Business logic that only works for one specific case. Settings buried in the code instead of a configuration file. These make the system fragile and hard to change.

Missing documentation. Almost every abandoned project has zero documentation. We build it as we go during the rescue process, so the next team (even if it's us) can understand the system without starting from scratch.

How to avoid this next time

A few things to put in place so you're never in this position again:

Own everything. You should own the code, the hosting accounts, the domain names, and the database. Not your developer. You. If they leave, everything stays with you.

Get the code stored somewhere you control. A code repository that you own, like a GitHub account in your name, means you always have a copy of the latest code. If your developer uses their own account, insist on a copy in yours.

Keep documentation current. Even simple notes about how the system works, where it's hosted, and what the passwords are. Keep them somewhere safe that doesn't depend on any one person.

Work with a team, not a solo person. When one freelancer goes dark, you're stuck. When a team has multiple people who know the system, losing one doesn't stop everything.