The first 48 hours after your developer disappears

Your developer hasn't responded in a week. Maybe two. The emails go unanswered, the Slack messages sit on delivered, and the phone goes straight to voicemail. You're staring at a system that runs a meaningful part of your business, and the only person who understands how it works has vanished.

You're not alone. According to compiled project management research, only about half of software projects deliver real value. PMI's 2025 global study of 5,800 project professionals found that 13% of projects fail outright, and only 50% are considered successful by all stakeholders. The rest land somewhere in between, and a significant portion of those end up in exactly the situation you're in right now: unfinished, undocumented, and untouchable.

Here's what to do, broken down by when to do it.

Right now: the emergency checklist

Before you call anyone, before you Google "software rescue company," do these things. They take an hour and they protect everything else.

1. Change every password your developer had access to. Hosting account. Domain registrar. Code repository (GitHub, GitLab, Bitbucket). Database. Payment processors (Stripe, PayPal). Email service (SendGrid, Mailchimp). Analytics (Google Analytics). Cloud services (AWS, Azure, Vercel). Every single one. If you share a password manager, revoke their access to that too. Enable two-factor authentication on everything.

2. Confirm you can access the source code. Log in to wherever the code lives. Can you see it? Can you download it? If the code is in your developer's personal GitHub account and not yours, you have a problem. If you can see it, download a complete copy to your own machine or cloud storage right now. Don't wait.

3. Verify your domain and hosting are in YOUR name. Go to your domain registrar and check that the registrant is you or your company, not your developer. Same for hosting. If the domain is in their name, contact the registrar about transferring it. This is urgent because if they let the registration lapse or transfer it away, your website disappears.

4. Check that backups exist. Can you find a recent backup of your database and application? If your developer was managing backups, you may not have one. If the hosting provider offers automatic backups, confirm they're running and download the most recent one. If no backups exist, this becomes your number one technical priority.

5. Document the current state. Open your application and screenshot every page, every workflow, every error you know about. If something breaks tomorrow, you want a record of what it looked like when it was working. This takes twenty minutes and will save you hours later.

Hours 2 through 12: figure out what you actually have

With access secured, you need to understand what you're working with. The answer falls into one of four categories, and the category determines everything that comes next.

State 1: You have the source code and it matches what's running in production. This is the best case. A new developer can pick it up, read it, and start working. The transition will take time and cost money, but it's manageable.

State 2: You have source code, but it's outdated. The code in the repository is from six months ago. Your developer made changes directly on the server and never committed them. A new team can still work with this, but they'll need to compare what's in the repo to what's actually running and reconcile the differences. Harder, but still salvageable.

State 3: You don't have the source code, but the application is running. The code lives on a server you can access, but there's no clean repository. A developer can pull the code from the server, create a proper repository, and go from there. It's messy, but the code exists.

State 4: You have nothing. No code, no server access, no backups. The application may still be running on infrastructure you can't reach. This is the worst case, and it usually means starting over. But even here, you can often reverse-engineer what the application does by using it and documenting every screen, every workflow, every data output. That documentation becomes the spec for the rebuild.

Most situations land in State 1 or 2. Industry experience suggests that 80 to 90 percent of existing codebases are salvageable, with serious problems concentrated in only 10 to 20 percent of the code. That's encouraging. It means you probably don't need to start over.

Hours 12 through 48: resist the three bad impulses

At this point you've secured your access and you know roughly what you're working with. Now is when most business owners make one of three mistakes.

The panic hire. You find someone on Upwork who says they can fix it by next week. They're cheap, they're fast, and they're available immediately. Here's the thing: anyone willing to start fixing code they've never seen, with no assessment, no audit, and no understanding of the architecture, is going to make things worse. A responsible developer will insist on understanding the system before touching it. If they don't insist on that, run.

The immediate rewrite. You decide the old code is trash and you want to start fresh. This feels clean and decisive. The reality is that rewrites routinely take two to three times longer than estimated. You're not just rebuilding the features you can see. You're rebuilding every edge case, every integration, every piece of business logic that was quietly handled in the existing code. Unless the codebase is genuinely unsalvageable (State 4 above, or built on a framework that's been abandoned), salvaging is almost always faster and cheaper.

The "I'll just wait" approach. You tell yourself the developer will come back. Maybe they're just busy. Maybe they had a personal emergency. And maybe they did. But every day you wait is a day the system runs without anyone who can fix it if something breaks. You don't have to fire them or burn the bridge. But you do need to start planning for the scenario where they don't come back. The two things can happen at the same time.

Day 2 through 7: get a professional assessment

This is the most important step, and it's the one most articles skip over. Before you hire someone to fix things, hire someone to tell you what's actually wrong.

A code audit typically takes a few days and costs between $2,000 and $5,000, depending on the size of the codebase. What you get back is a clear picture of where you stand: what's secure, what's not, what's maintainable, what's fragile, and what should be prioritized. It's the difference between a doctor diagnosing the problem and a doctor guessing based on your description of the symptoms.

Here's what a good assessment covers:

Security. Are there exposed credentials in the code? Open endpoints that should be locked down? Outdated libraries with known vulnerabilities? This is the most time-sensitive category because these are risks that exist right now, today, whether you know about them or not.

Architecture. How was the system built? Is it organized in a way that another developer can follow, or is it a tangle of spaghetti code where changing one thing breaks three others? This determines how expensive it will be to maintain and extend going forward.

Data integrity. Is the database healthy? Are integrations with other systems (your accounting software, your CRM, your payment processor) working correctly? Are they returning accurate data? We've walked into situations where the system appeared to work fine but was quietly feeding bad data to the owner's dashboards. The numbers looked reasonable. They just weren't right.

Bus factor. This is the number of people who need to disappear before a system becomes unmaintainable. If you're reading this article, your bus factor was one. A good assessment will identify not just the technical problems but the knowledge-concentration risks: what does this system depend on that only exists in one person's head?

The special case: your app was built with AI

There's a newer version of this problem that's showing up more often. Someone used Cursor, Bolt, Replit Agent, or another AI coding tool to build an application. It worked. It maybe even went to production. Then something broke, and the person who prompted the AI to build it can't fix it because they never understood the code in the first place.

AI-generated codebases have their own set of problems. A 2025 study by Veracode found that AI-assisted code introduced security vulnerabilities in 45% of the tasks they studied. Research from Autonoma analyzing 8.1 million pull requests found that AI-generated code accumulates technical debt at roughly three times the rate of human-written code.

The rescue process is the same (secure access, assess what you have, get a professional audit), but the findings tend to be different. Instead of a codebase that was intentionally designed and is just missing documentation, you get a codebase that was never designed at all. The AI generated whatever worked to pass the prompt, with no consideration for security, maintainability, or how the pieces fit together.

If this is your situation, we've written about the specific problems with vibe-coded applications and the security risks that come with AI-generated code.

Salvage vs. rebuild: how to decide

After the assessment, you'll have enough information to make this call. Here's a simple framework.

Salvage makes sense when: the application works and serves customers today, the source code is accessible and reasonably organized, the framework it's built on is still supported and maintained, the security issues are fixable without a ground-up rewrite, and someone other than the original developer can read the code and follow the logic. When these conditions are met, salvaging typically costs 40 to 70 percent of what the original build cost.

Rebuild makes sense when: the framework is abandoned or deeply outdated (Classic ASP, FoxPro, old PHP without a framework), the codebase is so tangled that fixing one thing consistently breaks others, there's no source code and no way to recover it, the security issues are so fundamental that patching them would mean rewriting most of the code anyway, or the application's requirements have changed so much that the existing system no longer fits the business. Rebuilds typically cost 80 to 100 percent of the original build, and they take two to three times longer than estimated.

The honest answer is that most projects should be salvaged. The impulse to start clean feels good but almost always costs more in time and money than fixing what's there.

What to look for in a rescue partner

When you're ready to bring in help, here's what separates a good rescue team from a bad one.

They insist on the audit first. Anyone who says "just send us the code and we'll start fixing things" hasn't done this before. A responsible team assesses before they act.

They give you a straight answer. After the assessment, they should be able to tell you: here's what's wrong, here's what it'll cost to fix, here's the priority order, and here's the honest timeline. If the answer is "it's going to be expensive and take a while," that's what they should say. You need the truth, not a sales pitch.

They've done rescue work before. Building software from scratch and rescuing someone else's code are different skill sets. Ask for examples. Ask what they found. Ask what went wrong and how they handled it.

They're a team, not a solo freelancer. You just lost a single point of failure. Don't replace them with another one. A small team of two to three people is enough for most rescues, but it should be more than one person.

They build documentation as they go. The whole reason you're in this situation is that the knowledge lived in one person's head. Any team worth hiring will document what they find and what they fix, so the bus factor never goes back to one.

Making sure this never happens again

Once the immediate crisis is handled, put these things in place so you're never back here.

You own every account. Domain registration, hosting, code repository, cloud services. All of them in your name or your company's name. Your developer gets access. They never own the account itself.

The code lives in your repository. Not your developer's personal GitHub. Yours. They push code there as they work. If they leave, the code stays.

Somebody else can deploy. At minimum, one other person in your organization should know how to deploy a code change, restart the application, and access the database. This doesn't require deep technical skill. It requires a written checklist and someone who's walked through it at least once.

Contracts include IP assignment. Your agreement should explicitly state that you own all code produced during the engagement, that the developer will transfer all access and documentation upon project completion or termination, and that they grant an irrevocable license to any libraries or tools they bring into the project. If your current contract doesn't say this, get it updated before the next project starts.

For a broader look at what the rescue process looks like from start to finish, we've written a companion piece: Your last developer disappeared. Now what?

Frequently asked questions

What should I do first when my developer disappears?

Secure your access immediately. Change passwords on your hosting account, domain registrar, code repository, database, payment processors, and any third-party services your developer had access to. Enable two-factor authentication everywhere you can. Do this before anything else, because if your developer's accounts are compromised or they decide to act in bad faith, you need those doors locked.

How do I know if my code is worth saving or if I need to rebuild?

It depends on four things: whether the code runs and serves customers today, whether you have access to the source code, whether the code was built on current frameworks or something outdated, and whether someone other than the original developer can read and understand it. Industry data suggests 80 to 90 percent of legacy codebases are salvageable, with problems concentrated in 10 to 20 percent of the code. A professional code audit, typically $2,000 to $5,000, will give you a clear answer within a few days.

How much does it cost to rescue an abandoned software project?

It varies based on the size and condition of the codebase. A code audit runs $2,000 to $5,000. Salvage and stabilization typically costs 40 to 70 percent of what the original build cost. Full rebuilds run 80 to 100 percent of the original cost, and research shows they routinely take two to three times longer than estimated. Salvaging is almost always the better first option.

Who owns the code if my developer disappears?

It depends on your contract. If you signed a work-for-hire agreement or your contract includes an IP assignment clause, you own the code. If there's no written agreement, copyright law defaults to the creator, meaning your developer may technically own the code even though you paid for it. Check your contract. If you don't have one, consult an attorney before making assumptions about what you can legally do with the codebase.

Should I hire a freelancer or an agency to rescue my project?

For a rescue specifically, a small team is almost always better than a solo freelancer. A rescue requires someone to audit the code, someone to assess the infrastructure, and ideally someone who can start fixing things while the assessment is still happening. A single freelancer becomes the same single point of failure you just lost. Look for a team that has done rescue work before and can show you examples.