It happens more often than anyone wants to admit. You hired a freelancer or a small agency, the project was moving along, and then silence. No commits, no replies, no explanation. Your developer disappeared mid project and you are sitting on a half finished codebase with a deadline approaching.
We have seen this scenario dozens of times. The good news is that it is almost always recoverable. The bad news is that what you do in the next 48 hours determines whether this is a setback or a catastrophe.
Do Not Panic, But Do Act Fast
The first instinct is to immediately hire someone new and tell them to finish it. Resist that urge. You need to understand what you actually have before anyone touches the code. Bringing in a new developer without an assessment is like handing someone a half assembled engine and saying "finish this" with no manual.
Start with these three steps:
1. Secure access to everything. Make sure you own the repository (GitHub, GitLab, Bitbucket), the hosting accounts, the domain, the database, and any third party service credentials. If the developer set these up under their own accounts, that is your first problem to solve. Every day you wait is a day they could delete something.
2. Document what was promised vs. what was delivered. Pull up your contract, scope document, or even email threads. Make a list of every feature that was supposed to be built and mark each one as complete, partially complete, or not started.
3. Get an honest technical assessment. This is where most people go wrong. They skip the assessment and go straight to "just finish it." You need someone experienced to look at the codebase and tell you what is actually there, not what it looks like on the surface.
How to Assess What You Have
A proper codebase assessment covers several areas. If you do not have the technical background to evaluate these yourself, this is exactly where a consulting engagement pays for itself in the first week.
Does it run? Can someone clone the repository, install dependencies, and start the application locally? You would be surprised how often the answer is no. Missing environment variables, hardcoded credentials, broken build scripts, these are red flags that the developer was the only person who could run the project.
Is there a database? If the application uses a database, is there a migration file or schema definition? Or was the database set up manually with no way to recreate it? This matters because without reproducible database setup, you are flying blind.
What is the test coverage? If there are no tests, every change the next developer makes is a gamble. They have no way to verify that fixing one thing did not break three others.
How is it deployed? Is there a CI/CD pipeline, or was the developer manually uploading files to a server? If it is the latter, you have a deployment bottleneck that needs to be solved before any new work starts. Our CI/CD pipeline guide covers what a proper setup looks like.
Is the code maintainable? This is subjective but critical. Is there consistent formatting? Are there comments explaining non obvious logic? Is the architecture organized or is everything thrown into one giant file?
The Three Scenarios You Are Probably In
Scenario 1: The code is 60%+ done and reasonably clean. This is the best case. A competent team can pick this up, fill in the gaps, and ship it. You will lose some time getting up to speed on someone else's code, but the foundation is solid.
Scenario 2: The code exists but is poorly structured. The features kind of work, but the architecture is a mess. This is the most common scenario we encounter. The question becomes rebuild vs. refactor, and the answer depends on how much of the codebase is salvageable. Sometimes it is faster to keep the database and rewrite the application layer.
Scenario 3: The code is unusable. Missing files, no documentation, hardcoded credentials everywhere, no tests, copy pasted Stack Overflow answers with the comments still in. This is effectively a restart, but you still have something valuable: the product requirements and design work from the first attempt.
What to Do Next
Once you know which scenario you are in, here is how to move forward:
Find the right replacement, not the fastest one. The temptation is to post on Upwork and hire the first person who replies. That is how you end up in this situation again. Look for a team with a track record of taking over existing projects, not just starting from scratch.
Insist on shared ownership from day one. The repository should be in your GitHub organization. The hosting should be under your account. The database should be in your cloud environment. Never let a developer be the single point of access to your own product. This is one of the core differences between working with a professional team vs. a solo freelancer, as we outline in our comparison of agencies vs. freelancers.
Set up checkpoints. Weekly demos of working software, not just status updates. If a developer cannot show you something running every week, something is wrong. This is the single best protection against another disappearance.
Get the documentation you were missing. A proper handoff includes a README that explains how to run the project, environment variable documentation, architecture decisions, and deployment instructions. If your previous developer never produced this, your new team should create it as part of onboarding.
Preventing This From Happening Again
The pattern behind most developer disappearances is the same: the project got harder than expected, the developer got in over their head, and instead of communicating, they went silent. It is not malicious, it is human nature.
You can prevent it by:
- Requiring weekly working demos, not reports
- Owning all accounts and credentials from day one
- Using milestone based payments instead of monthly retainers with no deliverables
- Choosing teams over solo developers because a team has built in accountability
A software development partner with an established process will have all of this baked in. You should never have to ask for it.
The Silver Lining
Losing a developer mid project is stressful, but it is also an opportunity to reset. You now have a clearer understanding of what you are building, what the pitfalls are, and what to look for in a development partner. The second attempt almost always goes faster because the requirements are battle tested.
If you are sitting on a half finished project right now and need an honest assessment of what you have, tell us about it. We will review your codebase, tell you what is salvageable, and give you a realistic plan to ship.