My Developer Disappeared: How to Rescue a Half-Finished Project

The message usually arrives on a weekday morning and reads something like this: "Our developer has stopped replying. The app is half finished. We have a launch commitment in six weeks, I don't have the passwords, and I don't know how bad it is. Can you help?"

When a project stalls and communication stops, start with facts rather than assumptions about the previous team’s motives. Establish what access you have, what the application currently does and what evidence supports the reported progress. A recovery assessment should identify options and risks before you commit to further development.

This is the guide for the day it happens: what to do immediately, how to find out how bad things really are, how to choose the developer who takes over, and how to make sure this never happens to you twice.

First, stop and secure. Do not shop yet.

Your instinct will be to immediately find a new developer. Resist it for one day. The first move is to secure what exists, because right now you may not actually own your own product.

Work through this list today:

1. The code. Do you have access to the repository (usually GitHub, GitLab or Bitbucket)? Is the account it lives under yours, or theirs? If it is theirs, your entire product currently exists at someone else's mercy.
2. The domain. Log into the registrar. If the domain was registered under the developer's account, this is your most urgent item, because losing a domain is losing the business's front door.
3. Hosting and database. Vercel, AWS, DigitalOcean, wherever it runs, and wherever the data lives. You need account-level access, not "they deploy it for me".
4. Third-party services. Payment processor, email service, analytics, app store accounts, API keys. List every service the product touches.
5. Change the passwords on everything you do control, and export a backup of the database and a copy of the code today, before anything else changes.

If access is missing, make a clear written request for the repositories, hosting, documentation and credentials your agreement entitles you to receive. Record what is available and what remains missing. Verify account ownership and authorization before changing access. If ownership or payment is disputed, obtain appropriate professional advice rather than treating an engineering checklist as legal guidance.

The deeper rule, and write this down for next time: the person who builds your product should never be the only person who can reach it. Everything registers under your accounts; the developer gets invited in. Any professional will find this arrangement completely normal. I insist on it with my own clients, for their protection and mine. Every account, code, domain, hosting, belongs to the client from day one.

Second, find out how bad it actually is

You cannot make good decisions, or brief a replacement, without knowing what state the project is really in, and you currently have only two data points: what the old developer claimed, and what you can see on the screen. Neither is reliable. "Ninety percent done" is the most common phrase in this genre and it is almost never true; the last ten percent of a claimed project routinely contains half the work.

What you want is a technical assessment: a few paid hours from an experienced developer, on hourly terms, producing plain-English answers to five questions.

1. Does the code actually run, from scratch, on a fresh machine? (You would be amazed how often the answer is no.)
2. What genuinely works end to end, versus what merely has screens?
3. What is the quality of what exists: reasonable foundations, or structural problems?
4. Is it built on a sane, mainstream stack that other developers can pick up?
5. The verdict: continue this codebase, or is a restart honestly cheaper?

Compare repair, selective replacement and rebuilding using findings from the actual application. Ask what is broken, how it was verified, the cost and risks of each option, and which assets can be retained: requirements, designs, data, working features or tests. A restart needs a concrete justification, not an assumed base rate about other projects. Preserve useful work where it is safe and practical to do so.

Pay for this assessment as its own small engagement, with no commitment beyond it. A few hundred dollars here informs decisions worth tens of thousands.

Third, choose the continuation developer carefully

You are now hiring under pressure, which is exactly when people repeat the mistake that got them here. The full playbook is in my founder's guide to hiring a full stack developer, but rescue situations add specific requirements.

You want someone who has taken over existing codebases before, and can tell you stories about it: what they found, how they proceeded. Taking over code is a distinct skill from writing it; ask directly. You want someone who starts hourly or with a small first milestone, because nobody honest can fix-bid a codebase they have not lived in yet; I have written about why in fixed price versus hourly. And you want someone whose first deliverables are stabilizing ones: getting the project running reproducibly, writing down how it deploys, and putting the existing work under version control and backups if it somehow is not.

Red flags, amplified for rescues: anyone who quotes a fixed price for the whole remaining project sight unseen; anyone whose first assessment is a sneer and a rewrite pitch without specifics; and anyone who wants to migrate you to their preferred stack when the current one is mainstream and healthy. The stack almost never caused your problem. The working arrangement did.

Expect the first week or two to look slow. The new developer is reading, mapping, and firming the ground before building on it. This is what competence looks like in a takeover; the alternative, building fast on unexamined foundations, is how one rescue becomes two.

Fourth, resume, with the guardrails that were missing

Once stabilized, the project continues like any healthy engagement, and "healthy" is precisely the thing that was absent before. The pattern that prevents a second disappearance is boringly simple:

• Weekly demos of working software. Not status reports, the actual product, growing. Silence for two weeks was your earliest warning sign last time; make it structurally impossible.
• Your accounts, their invitation. Already covered, never again negotiable.
• Written scope in small increments, so both sides always know what "this week" means.
• Money follows delivery, milestone by milestone, so neither side ever carries dangerous exposure to the other.

None of this is adversarial. Good developers thrive under these arrangements, because the same structure that protects you from a vanishing developer protects them from vanishing clients, moving goalposts and unpaid invoices. If a candidate resists visibility and shared access, that resistance is information, and it is the exact information you wish you had noticed last time.

What this costs, honestly

A takeover includes assessment, stabilization and learning unfamiliar code. Estimate that work from repository size, deployment reproducibility, dependencies, data access and test coverage rather than promising a standard number of weeks. Compare each option’s remaining cost, risks and acceptance criteria from today. Track assessment and recovery as explicit milestones before resuming feature development.

One more honest number: some rescued projects discover mid-rescue that the original scope was the real problem, too big, too vague, priced on hope. If that is you, shrinking the target is not failure. Shipping a smaller working product beats owning a larger abandoned one, every single time.

If you are in this situation right now

Take the securing steps above today; they cost nothing and stop the bleeding. Then get the assessment before committing to anyone for the rebuild, even me.

Project takeovers are a normal part of my work: assessment first as a small standalone engagement, honest verdict including "continue with someone cheaper than me" or "this needs less work than you fear", then stabilization and weekly-demo delivery if we continue. If your developer has gone quiet and you want a second pair of eyes on what they left behind, tell me what you know about the project, and I will tell you what an assessment would cover for your specific case. Bring whatever access you have; we will inventory the rest together.

Quick answers

My developer has the only copy of the code. What do I do? Request the handover specified in your agreement and document the response. Check repositories, hosting exports and backups you are authorized to access; a deployed application is not necessarily a complete or maintainable source-code copy. Seek appropriate professional advice if rights or payment are disputed.

Do I legally own the code I paid for? It depends on your contract and jurisdiction; freelance work without a written transfer can leave copyright with the author. Practically: get the code and accounts into your possession first, and have any new contract state plainly that all work product belongs to you on payment.

How do I know if the old code is good enough to keep? You don't, and neither does anyone who has not read it. A short paid technical assessment answers it with evidence. Distrust instant verdicts in either direction.

Should the new developer rewrite from scratch? Sometimes, but demand specifics before accepting it: what is broken, why repair exceeds rebuild, and what carries over. Requirements, designs and lessons learned survive even when code does not, so a "restart" is never truly from zero.

How do I stop this happening again? Own every account, see working software weekly, pay in small increments against delivery, and keep scope written down. Disappearances almost never come out of nowhere; they come out of arrangements with no visibility, where things can go quietly wrong for months.