Your developer disappeared. Here is how to rescue what they left behind.

Your developer stopped answering three weeks ago. The website is half-built, the app is not finished, and you have already paid most of the fee for something that does not work, built by someone you cannot reach. This happens in South Africa more often than the industry admits, and I get these calls regularly. The money is probably gone, but the project usually is not. Here is what to do.

Step 1: Secure What You Can Right Now

Before anything else, make sure you own and control the things that matter. Some of these may be registered in the developer's name or on their accounts. The longer you wait to sort this out, the harder it gets.

Your domain name. Is it registered in your name or the developer's? Check the WHOIS record (use whois.domaintools.com or a similar tool). If the domain is in the developer's name, you need to arrange a transfer. If they are truly unreachable, this becomes a legal matter, but start by checking.

Your hosting account. Is the site hosted on your account or the developer's? If it is on their hosting, your entire site depends on them continuing to pay for that server. Get a copy of all files and the database now. Move to hosting you control as soon as possible.

Your email. If your business email runs through the same hosting or domain, it is at risk too. Prioritize this. Losing your website is bad. Losing your business email is worse.

Source code. Do you have a copy of the code? Was it in a Git repository you have access to? On a server you can access? If the developer was the only person with access to the code, getting a copy is your first priority. Without the code, the next developer cannot continue the project.

Credentials and accounts. Payment gateway logins. Analytics accounts. Social media accounts connected to the site. Any third-party service the developer set up. Collect these now.

Step 2: Find Out What You Actually Have

Once you have secured access, you need an honest assessment of what was built. Not what was promised. What actually exists and works.

This is where most business owners get bad advice. They contact a new developer, the new developer looks at the code, and says: "This is terrible. You need to start over."

Sometimes that is true. Sometimes the new developer just prefers to build from scratch because reading someone else's code is harder than writing your own. Starting over is easier for the developer but more expensive for you.

Before accepting "start over" as the answer, get an honest code audit. Here is what to look for.

Does the core structure work? Is the site built on a reasonable platform (WordPress, Shopify, React, Laravel, etc.)? Is the database structure logical? Are the main features functional or close to functional?

How much is done? Not by feature list, but by working functionality. A developer might say they are "80% done" but if the remaining 20% is payment processing, user authentication, and the admin panel, you have the easy 80% and the hard 20% is still unfinished.

Is the code maintainable? Can another developer read this code and continue working on it? Or is it written in a way that only the original developer could understand? This is the real question. Messy but functional code can be cleaned up. Undecipherable code cannot.

What is missing? Make a list of every feature that was promised and mark it as done, partially done, or not started. This gives you a realistic picture of how much work remains.

Step 3: Decide Whether to Finish or Rebuild

This is the hard decision. Both options cost money. Here is how to think about it.

Finish the existing work when:

• The core structure is solid
• 50% or more of the functionality works
• The code is readable by another developer
• The technology choices are reasonable and current
• The remaining work is clearly definable

Rebuild from scratch when:

• The code is unmaintainable (no other developer can work with it)
• The technology choices are outdated or inappropriate
• The architecture cannot support what you need (wrong foundation)
• Security is compromised (hardcoded passwords, no input validation, SQL injection vulnerabilities)
• Less than 30% of the work is actually done despite claims of being "nearly finished"

The honest middle ground: Sometimes the right answer is to keep parts and rebuild others. Use the existing database design but rebuild the front end. Keep the working payment integration but redo the user authentication. A good developer will evaluate this honestly.

Common Patterns I See

Having rescued several projects like this, certain patterns repeat.

The "almost done" trap. The developer said the project was 90% complete six months ago. It is still 90% complete. The final 10% (testing, bug fixes, edge cases, deployment, security) is often 50% of the actual work. When a developer disappears at "almost done," they usually hit the hard part and stopped.

No version control. The developer was working directly on the live server or on their personal machine. There is no Git history, no deployment process, and no way to see what changed or when. This makes continuation much harder.

The hosting hostage. The site is on the developer's hosting account. They are unreachable. You cannot access the files. In some cases, the developer does not respond but the hosting stays active. In others, they stop paying and the site goes offline. This is preventable.

Scope was never defined. There was no written scope document. The project was a series of conversations and messages. Both sides had different understandings of what "done" meant. This is the root cause of most abandoned projects.

How to Prevent This Next Time

When you hire your next developer, protect yourself from the start.

Own everything yourself. The domain registration, the hosting account, the Git repository, all third-party service accounts. The developer should have access to your infrastructure, not the other way around.

Get a scope document in writing. Not a proposal. A scope document that lists every feature, every page, every integration, and what "done" looks like for each one. Both sides sign it.

Pay per piece you can see. Never pay for the whole project up front. Pay per piece of work you can see working: a written plan first, then each working piece, on the terms written in its quote. If a developer disappears, you've lost one piece at most, so check what your agreement says about ownership of what was delivered. That's how I work too: you pay per piece, and there's no single bill for the whole project up front.

Insist on version control. The code should live in a Git repository your business controls access to (GitHub, GitLab, Bitbucket). Every commit is visible. If the developer disappears, you have the complete code history and can hand it to someone else.

Check references. Not the portfolio. Talk to actual clients. Ask: "Did they finish the project? Did they communicate? Are they still reachable?" Past behavior predicts future behavior.

A Real Recovery

I took over a WordPress project for Buffet Olives where the site needed data recovery and continuation after the previous development arrangement fell apart. The project required recovering existing content, rebuilding what was lost, and delivering a working site the business could rely on.

The Short Version

Your developer disappeared. That is frustrating and expensive, but the project is probably not lost. Secure your domain, hosting, and code access first. Get an honest audit of what was built before accepting "start over." Decide whether to finish or rebuild based on code quality, not emotion. And protect yourself next time with clear ownership, written scope, payment per piece, and version control.

If you are stuck with a half-built project and need someone to assess what is there and help you finish it, tell me the problem.