Web developer disappeared mid-project

The developer stopped replying three weeks ago. The site is half built, the staging link now shows a hosting error, and the last invoice was paid in full. You don't know where the code lives, who owns the domain, or whether anything you paid for can actually be handed to someone else. Most people's first instinct is to find a new developer and start again. Usually that's the expensive option.

I pick up a fair few of these, mostly Laravel builds and WooCommerce stores that were left somewhere between "nearly done" and "live but fragile". Below is the order I work through before anyone writes a line of new code, because what you can recover decides what the next job actually costs.

Secure the accounts before anything else

Code can be recovered later. Access to the domain and hosting is the bit that can really hurt you if it's in someone else's name. So the first hour goes on working out who controls what.

• Domain registrar: whose account is it in, and when does it renew?
• DNS: is it at the registrar, Cloudflare, or the hosting company?
• Hosting or server: shared hosting, a VPS, Forge, Ploi, a managed WordPress host?
• Email: is your business email running through the same hosting account?
• Payment and third-party services: Stripe, PayPal, Mailgun, Postmark, Google Workspace, any API keys the site depends on

If the domain is registered to the developer personally, sort that first. A lapsed renewal on a domain you don't control takes your site and your email down together, and getting it back is slow.

Find out where the code actually lives

Ask the obvious question before digging: was there a Git repository? Check your email for invites from GitHub, GitLab or Bitbucket. Developers often added clients to a repo early on and then forgot about it.

If there's no repo, the code on the server is the only copy. That's fine, but treat it carefully. Take a full download of the files and a database export before anyone touches anything. For Laravel that means the whole project including composer.json, composer.lock and the .env file. For WordPress it means wp-content, wp-config.php and the database.

Don't assume the live server matches the latest work either. I've seen plenty of projects where the finished features only existed on the developer's laptop.

Work out what state the build is really in

A half-finished project is rarely half finished in a neat, even way. Some parts are done properly, some are placeholders, and some look finished on the front end but do nothing behind it.

• Run through every page and form as a real user would and note what breaks
• Check the admin side, not just the public site. Unfinished work often hides there
• Look for hardcoded test values, dummy products, and payment gateways still in test mode
• Check scheduled tasks, queues and emails. In Laravel, look at the scheduler and whether a queue worker is even running

At the end of this you want a plain list: works, half works, missing. That list is worth more than the original spec, because it's based on what's there rather than what was promised.

Check the code quality before deciding to keep it

This is where it's easy to get bad advice. Some developers will tell you everything needs rewriting because it's easier for them to start from scratch. Sometimes that's true. Often it isn't.

What I look at is fairly boring. Is it on a supported version of Laravel or PHP? Are dependencies locked and installable? Is the database structure sensible, or is everything crammed into one table? Is business logic scattered through the views? Are there obvious security gaps, like unvalidated input or secrets committed to the repo?

If the foundations are reasonable, finishing and tidying is almost always cheaper than rebuilding. If you want more detail on that side of it, I've written about taking over a Laravel codebase with no documentation and about the gotchas in inherited WooCommerce stores.

Check who owns what you paid for

I'm not a lawyer, so this is the practical version rather than legal advice. Look back at the contract, the quote, or even the email thread where the work was agreed. If it says anything about ownership of the code on payment, keep a copy of it.

Also check premium plugins, themes and licences. It's common for a developer to install a premium WordPress plugin on their own licence. That keeps working until the licence expires, and then updates quietly stop. Make a list and plan to move them onto licences in your name.

Decide: finish, stabilise, or rebuild

Once you know what you've got, the options are usually one of three.

• Finish it: the code is sound and the gaps are clear. Fastest route to live.
• Stabilise it first: the site works, but it's fragile. Get it onto proper hosting, into version control, updated and backed up, then carry on building.
• Rebuild parts of it: one area is a mess but the rest is fine. Replace the bad section rather than everything.

A full rebuild does happen, but it should be the conclusion after looking at the code, not the first thing someone suggests before they've opened it.

A checklist for this week

1. List every account the project touches and confirm who controls each one.
2. Move the domain into your own name if it isn't already.
3. Take a full backup of the files and database from the server.
4. Look for a Git repository and ask for access if one exists.
5. Walk the whole site and write down what works, half works and is missing.
6. Find your contract or agreement and any premium licences in use.
7. Get a second developer to review the code before deciding to rebuild.

Even if the original developer does come back, you'll be in a much better position having done this.

This kind of rescue work is a big part of what I do, particularly on Laravel applications and WooCommerce stores. I'll look at what's there, tell you honestly whether it's worth finishing, and then either finish it or keep it running with ongoing maintenance. I also pick up stalled projects for agencies on a white-label basis.

See how I can help →

When a developer vanishes mid-project, the panic is usually about the code, but the real risk is the accounts. Lock down the domain and hosting, get a copy of everything, work out what's actually finished, and only then decide what the next job looks like. Cheers.