Your developer stopped responding: 5 things to do before you panic

You wake up one morning, message your developer, and nobody answers. A day goes by. Two. A week. The project is on hold. You don't have access to the code. You don't know exactly what's been done. And now you need to figure out a way out — ideally without throwing away the months of work you've already paid for.

This article isn't theory. It's what I do when a founder calls me with this problem, and it's the exact sequence I have them follow in the first 48 hours.

First: figure out whether it's actually serious

Not every silence is a disappearance. There's a huge difference between a dev who hasn't replied for 3 days because of a personal issue, and one who stopped working for you weeks ago. Before switching into emergency mode, check these three signals:

• More than 7 days of silence after you've reached out on 2 different channels (email + Slack/WhatsApp).
• No recent commits on the repository — if you have access to GitHub/GitLab, check the latest activity. Nothing for 2+ weeks is a very good reason to worry.
• Recent payments don't match delivered work. If you've paid for the last two milestones and can't see what was done, you're already in risky territory.

If two or three of these signals are present, stop waiting and follow the 5 steps below. Every day that passes makes recovery harder.

Step 1 — Recover access to everything, now

The first thing you do today, not tomorrow: rebuild the complete list of accesses you should have and check which ones you're missing.

Minimum list:

• Code repository (GitHub, GitLab, Bitbucket). You need to be owner or admin — not "contributor".
• Hosting / cloud provider (Vercel, AWS, Hetzner, etc.) — you need to own the account, or at least have access to billing and deployments.
• Domain and DNS — this is where you can get burned the most. If the dev registered the domain in his own name, you have a serious problem.
• Database and backups — access, or at least a recent backup you can restore yourself.
• Third-party services — Stripe, Mailchimp, Twilio, etc. Every provider needs to have YOU as the owner.
• Documentation — Notion, Google Drive, anywhere specs, passwords or runbooks live.

If any of these are missing, act today. Many providers have account recovery procedures for legal disputes if the domain or cloud account is registered to the company with proof of payment. Contact their support right away.

If instead the dev registered everything under his personal name — domain included — understand that you have a legal problem, not just a technical one. A lawyer who handles intellectual property costs you less than a month of lost development.

Step 2 — Take a snapshot of the project's state

Once access is recovered, you need to understand where you really are. Not what the dev claimed he had done. What actually exists today in the code and in production.

To do within 24-48 hours:

1. Clone the repository and take a look at the structure. Even if you can't read code, count how many files/folders there are and when the last commit was.
2. Open the production version (if it exists) and test every feature one by one. Note what works, what doesn't, what's incomplete.
3. Compare against the feature list the dev was supposed to deliver. How many are actually in production? How many are "almost done"? How many were never started?
4. Save everything in a shared document — you'll need it both for the handover to the next dev, and potentially in case of legal action.

This document — call it "Current state of the project" — is the foundation any new dev or consultant can build on. Without it, every newcomer will have to redo the discovery work from scratch, adding weeks to the timeline.

Step 3 — External technical audit (the mistake of NOT doing it)

At this point the temptation is enormous: hire another freelancer right away, show them the code, and say "finish what's missing". Don't do it.

Three reasons:

• You don't know whether the existing code is worth saving. The next dev will always tell you it's worth rebuilding from scratch — it's in his economic interest. Without an independent assessment, you can't decide.
• You don't know how much time is really needed. Without an audit, the next freelancer's quote will be optimistic (to close the deal) and will balloon along the way (because he'll discover problems that could have been spotted earlier).
• You don't have a prioritized intervention plan. The next dev will start from the part that excites him most, not from the one that gets you to production first.

The most sensible thing to do now is an external technical audit — one that's independent from both the vanished dev and the next one you'll hire. In 2-3 days it produces a written report with: what works, what's salvageable, what needs rewriting, and a prioritized intervention roadmap.

It costs a few hundred euros. It saves you thousands. I wrote about it in detail on the software audit page.

Step 4 — Decide: unblock, replace, rewrite

With the audit in hand, you finally have the data to make a real decision. There are three options, and none of them is inherently wrong — it depends on your specific case.

Option A — Unblock

When it makes sense: the existing code is salvageable, 60-80% of the work was done well, what's left is finishing 2-3 features and shipping to production. Timeline: 2-4 weeks. Cost: far lower than rebuilding. This is the right path for 80% of the cases I see.

Option B — Replacing the dev

When it makes sense: the existing code is decent, the relationship with the previous dev was the problem (not the work done). Careful: the next dev must be selected with an independent audit behind you, not with standard interviews.

Option C — Rewriting from scratch

When it makes sense: the code is genuinely unsalvageable (rare), or the architectural choices are so wrong that recovering them costs more than redoing. A rewrite always looks faster, but it almost never is — you have to redo even the decisions the previous dev got right, on top of the wrong ones.

The rule I give my clients: rewriting from scratch makes sense only if the audit explicitly tells you that >70% of the code has to go. Below that threshold, unblocking is almost always the economically better choice.

Step 5 — What NOT to do

Five catastrophic mistakes I see founders make in this situation. Avoid them and you've already solved half the problem.

1. DON'T hire the first freelancer you find on Upwork or LinkedIn to "finish the job". Taking over a project wounded by a "previous dev vanished" scenario is a minefield. It takes seniority, not immediate availability.
2. DON'T threaten legal action via WhatsApp to the vanished dev (even if he deserves it). If legal action is needed, have a lawyer handle it. Meanwhile, you need to focus on the project.
3. DON'T pay the next dev upfront for more than 1-2 weeks. You've already been burned once. Payments against delivered milestones, always.
4. DON'T sign an annual contract with the next CTO or agency. Start with a trial quarter.
5. DON'T try to read the code to judge whether it's done well (unless you're technical). That's exactly what the audit exists for.

How to prevent it next time

Almost every founder who ends up in this situation tells me the same thing: "he seemed like a reliable person". And he probably was. The problem isn't trust. The problem is the lack of safety systems.

Four practices that eliminate 90% of this risk:

• You own everything. Repo, hosting, domain, third-party accounts. The dev gets access as a collaborator, never as owner.
• Visible weekly commits. Even if you don't read code, check that new commits land every week. A dev who has stopped committing has stopped working.
• Bi-weekly demos in production. A 20-minute call every 2 weeks where the dev shows you what's live (not "almost ready"). If he refuses, that's a huge red flag.
• A technical audit every 6 months. An external assessment twice a year. It costs little and prevents 80% of incidents.

Wrapping up

Your developer stopped responding. It's not the end of the world, but you've treated it like it was until now — because you were on your own. Starting today, you're not. Follow the 5 steps in order:

1. Recover access to everything (today).
2. Take a snapshot of the project's state (48 hours).
3. Get an external audit (2-3 days).
4. Decide between unblocking, replacing, rewriting (based on data).
5. Avoid the 5 mistakes above.

On the first point — the most urgent — I wrote a detailed guide: how to recover source code, domain and access when you're holding nothing.

Frequently asked questions

If you want to speed things up and have someone who has already seen this situation 20 times, give me a shout. I audit and unblock projects like this — the first call is free and I reply within 24 hours.