It starts with slower responses. Then missed deadlines. Then silence. If your developer — freelancer, agency, or in-house — has gone dark mid-project, here's what to do. Step by step, starting right now.

First: don't panic. But do act fast.

This happens more often than anyone talks about. A developer disappearing mid-project — whether a freelancer who ghosted, an agency that went quiet, or a full-time hire who left suddenly — is one of the most common crises non-technical founders face.

The good news: your project is almost certainly recoverable. The bad news: every week you wait makes recovery harder. Code without context decays fast. Servers without someone watching them drift. Customers without updates leave.

Step 1: Secure your assets (today)

Before anything else, make sure you have access to and control over everything:

Source code. Is it in a Git repository you own (GitHub, GitLab, Bitbucket)? If the code lives on the developer's personal account, you need to get it moved immediately. If you don't have access to the repo at all, that's your first emergency.
Hosting and infrastructure. Where is the app deployed? Who owns the AWS/Vercel/Heroku account? Who controls the domain? If the developer set these up under their own accounts, you're at risk of losing access.
Databases and data. Where does user data live? Do you have backup access? Can you export it?
Third-party services. Payment processor, email service, analytics, API keys. Change passwords and rotate any keys the developer had access to.
Documentation. Collect any specs, design files, Slack messages, or email threads that describe what was built and what was planned.

This step takes an afternoon, not days. Do it before anything else.

Step 2: Assess the damage (this week)

Once you have access, you need to understand what you actually have. This is where a technical person — even for just a few hours — is critical. You need answers to:

Does the code run? Can someone clone the repo, install dependencies, and start the application locally?
Is the deployed version stable? Is the live app still working for users? Are there errors piling up in the background?
What was in progress? Check the last commits, open pull requests, and any project management tools for unfinished work.
How is the code structured? Is it reasonably organized or a tangled mess? This determines whether a new developer can pick it up or if significant cleanup is needed first.

Step 3: Decide — rescue or rebuild

After the assessment, you're in one of three situations:

Situation A: The code is solid, it just needs a new driver

The previous developer did good work. The codebase is organized and documented well enough for someone new to pick up. You just need a replacement. This is the best case scenario.

Situation B: The code is messy but salvageable

The work is partially done, partially broken. A senior engineer can stabilize it, clean up the worst parts, and get it shipping again. This is where a rescue engagement makes the most sense.

Situation C: The code is unsalvageable

This is rare, but it happens — especially with very junior developers or offshore agencies that cut extreme corners. If the assessment says rebuild, the silver lining is that you now have a working spec (the existing app) and know exactly what needs to be built.

Most codebases fall into Situation B. The developer wasn't bad — they just left before the code was production-ready. A targeted cleanup is almost always faster and cheaper than a full rewrite.

Step 4: Find the right replacement

Resist the urge to grab the cheapest freelancer on Upwork. You already got burned once — don't repeat the pattern. Here's what to look for:

Experience with rescues specifically. Picking up someone else's code is a distinct skill. Not every good developer is good at it.
Willingness to audit before committing. Anyone who gives you a fixed-price quote without looking at the code first is guessing.
Clear communication. The #1 reason developer relationships fail isn't skill — it's communication. Weekly updates, honest timelines, and proactive flagging of problems.
References you can actually call. Not testimonials on their website — real people who hired them for similar work.

Step 5: Prevent it from happening again

Once you're through the crisis, set up guardrails:

Own all accounts. Code repos, hosting, domains, databases, third-party services — all under your company's accounts, always.
Require documentation as you go. A simple README that explains how to run the project. Architecture decisions written down. Not a novel — just enough that someone new could pick it up.
Set up CI/CD early. Automated testing and deployment means the project can keep running even if the person maintaining it changes.
Never have a single point of failure. Even if you have one primary developer, make sure at least one other person has access to everything and a general understanding of how it works.

You'll get through this

Losing a developer mid-project feels like a crisis. It is one — but it's a recoverable one. We've stepped into projects where the previous developer vanished months ago and the founder had given up hope. Every single time, the project was salvageable.

Secure your assets, get an honest assessment, and bring in someone who has done this before. You'll be shipping again sooner than you think.

My Developer Disappeared: The Founder's Recovery Playbook