Your Developer Disappeared Mid-Project. Here's What to Do First.

Maybe the messages slowed down first. Replies that used to come in an hour started taking three days. Then the weekly demo got skipped, "just this once." Then an invoice arrived without the work it was supposed to cover. And now it's been two weeks, or a month, and you're rereading the last message you sent — polite, slightly desperate — to someone who is clearly never going to answer it.

We take over projects in exactly this state, so let us say the thing you most need to hear first: this is common, it is survivable, and the next few decisions matter more than anything that has happened so far. Most of the lasting damage we see in abandoned projects wasn't done by the developer who left. It was done in the panicked month after, by decisions that felt reasonable at the time.

Here is what to do, in order.

1. Confirm it's actually abandonment

Before anything else, separate gone from late. Freelancers get sick, agencies have bad months, and a developer who resurfaces to find you've locked them out of everything is a working relationship you've destroyed for nothing.

A reasonable test: one clear, unemotional message that asks for a specific reply by a specific date. Something like: "I need to know the current state of the project and when you can next work on it. If I don't hear from you by Friday, I'll have to assume you're no longer available and make other arrangements."

No reply to that — a concrete question, a fair deadline, a stated consequence — is your answer. You're not being dramatic by moving on. You're being responsible.

2. Inventory what you own — and what you can actually get into

This is the step people skip, and it's the one that determines how bad the next six months are. Sit down and list every account and asset the project touches, and for each one, answer two questions: whose name is it in? and can I log in right now, without the developer?

The usual list:

• The code repository — GitHub, GitLab, Bitbucket. This is the single most important item on the page.
• Hosting and infrastructure — the cloud account the app runs in, and the billing attached to it.
• The domain name — registrar account, DNS settings.
• Databases — where the actual data lives, and whether anyone has a backup.
• App store accounts — Apple and Google developer accounts, if there's a mobile app. These are slow to untangle and worth starting early.
• Third-party services — payment processors, email senders, analytics, and every API key the app depends on.
• Passwords and access — the email address password resets go to. If that's the developer's address, flag it now.

Everything in your name that you can access: fine. Everything in their name: write it down as a risk. You'll work through that list in step four.

3. Get the code — the real code, all of it

If you have access to the repository, take a full copy today. Not a zip file someone sent you three months ago — the live repository, with its complete history. The history matters more than people expect: it's often the only honest record of what was built, when, and by whom, and whoever takes the project over will lean on it heavily.

If you don't have access, requesting it is your first and politest demand. Depending on your contract, code you paid for is very likely yours, and most developers — even ones who've gone silent — will hand over a repository when asked plainly, because withholding it turns an awkward exit into something with legal weight.

While you're at it: get a copy of the production database, and confirm where backups live and that one has actually run recently. An app can be rebuilt. Your customer data can't.

4. Write down the state of things — before you change anything

Take an hour and document, in plain English, three lists:

1. What was promised. The contract, the proposal, the feature list — whatever was agreed.
2. What was paid. Invoices and dates.
3. What demonstrably works. Not what the developer said was done — what you can personally click through and see working today.

The gap between list one and list three is the honest size of your problem, and you want it written down now, while access still works and memories are fresh. If the situation ever involves a dispute, a refund negotiation, or a lawyer, this hour is the best-spent hour of the whole ordeal. And even if it never comes to that, the next developer will ask for exactly these three lists.

One boundary we should be clear about: we rescue codebases, not contracts. If real money is stuck in this — large prepayments, a signed agreement that was clearly breached — what you need for that part is a lawyer in your jurisdiction, not a development team's opinion.

5. Don't make the second mistake

The first mistake was made by someone else. The second one is the one we're trying to talk you out of, and it comes in two flavors.

Flavor one: "just finish it." You find a new developer, show them the app, and ask them to pick up where the last one left off — without anyone actually reading what's there. The new developer, who wants the job, says some version of "shouldn't be a problem." Three weeks later you're getting the same slowing-down messages, because they've discovered what the last developer left behind and don't know how to tell you.

Flavor two: "burn it down." You're angry, the code feels contaminated, and rebuilding from scratch sounds cleansing. Sometimes a rebuild genuinely is the right call — but deciding that while angry, without evidence means paying for the same software twice on the strength of a feeling.

Both mistakes have the same root: making a build-on-it-or-rebuild-it decision before anyone qualified has read the code. Which is why the actual next step is smaller and less dramatic than either.

6. Get the code read before you spend another peso or dollar on it

What you need now is not a developer who promises to finish. It's an honest, written answer to three questions:

• What state is this actually in? What works, what's half-built, what's broken?
• What's salvageable? Is this a foundation or a liability?
• What would it take to finish? A real plan, not a vibe.

That's precisely what our free project rescue assessment is: we read the codebase and give you a written verdict, a risk map, and a plan — in 48–72 hours, at no cost, with no obligation to hire us for what comes after. It's yours to keep, including if you hand it to a different team entirely. And if the honest answer is "this is 80% done and the last developer was better than you think," the write-up will say that too — it happens more often than you'd expect.

However you get it done — us, or any senior developer you trust — do not skip this step. Every bad outcome we've seen in a rescue started with someone building on a foundation nobody had inspected.

What recovery actually looks like

From the other side of this, having taken over stalled and abandoned projects many times: the situation is almost never as bad as it feels in the week you discover it, and almost never as simple as the next eager developer says it is. The truth sits in the middle, and it's findable — in the repository history, in the state of the code, in the gap between your three lists.

You'll lose some time. You may lose some money you've already spent. But the project itself — the thing you were trying to build — usually survives, provided the next few decisions are made on evidence instead of adrenaline.

Secure your access, get the code, write down the state of things, and make someone read it before anyone writes another line. That's the whole playbook for week one.