If your web developer has stopped replying and the website is still unfinished, do not pay a second person to rebuild it before you know what you already own.
Your first job is recovery, not redesign.
Secure the accounts, preserve the current work, identify what is actually incomplete, and only then decide whether another developer should finish, repair or rebuild it.
A half-finished website can still contain valuable work: approved copy, page structure, design files, working integrations, SEO URLs, analytics history and usable code. The expensive mistake is throwing those assets away because the project feels chaotic.
First, separate a communication problem from a website emergency
A developer missing one message is not the same as a project being abandoned.
Check the agreed communication schedule, milestones and delivery dates. Send one clear written request asking for:
- current project status;
- outstanding deliverables;
- source-code location;
- deployment or hosting location;
- credentials or ownership transfers still outstanding;
- the latest working version;
- any unpaid invoice or disputed scope item;
- a reasonable response deadline.
Keep that request factual. The goal is to establish the state of the project and create a clean record before you start changing systems.
If the developer returns and the issue is simply a missed handoff, you may avoid an unnecessary takeover entirely.
If they do not, move to asset recovery.
Secure the assets the business cannot afford to lose
Make an ownership inventory before anyone touches the build.
For a normal business website, I would check these first:
- Domain registrar: who owns the domain account and whose email controls recovery?
- DNS: where are the DNS records managed?
- Hosting or deployment: which account actually serves the live website?
- Source code: is there a GitHub, GitLab or other repository, and is it in an account you control?
- CMS and database: can you access the content and data?
- Business email: are website and domain recovery emails tied to an address you control?
- Analytics and Search Console: can the business still see its historical performance?
- Forms and CRM: where do enquiries go?
- Payment accounts: if the website takes money, are the merchant and payment-provider accounts owned by the business?
- Design and content files: do you have the approved copy, images, brand assets and design source files?
Do not confuse having a website password with owning the website’s infrastructure.
A developer may have given you WordPress admin access while the domain, hosting and backups remain in their personal accounts. Or you may own the domain while the only current source code exists on somebody else’s laptop.
Those are very different takeover risks.
Preserve the current state before making fixes
When a project feels abandoned, there is a temptation to immediately reset passwords, install plugins, move hosting and ask a new developer to “just make it work.”
Preserve evidence first.
Where possible, record:
- the live URL and important page URLs;
- screenshots of the current site;
- the current repository and latest commit;
- the deployed version or build identifier;
- database and file backups;
- DNS records;
- current forms and their destinations;
- analytics and Search Console access;
- known bugs and unfinished pages.
Then change credentials that genuinely need to be secured.
This matters because the next developer needs to distinguish what was already broken from what changed during the takeover.
It also gives you a rollback point if an emergency repair makes things worse.
Do not judge completion by how finished the homepage looks
A polished homepage can hide an unfinished system.
Before requesting a rescue quote, test the website as a customer would.
For a service business, that might mean:
Google or referral → landing page → service page → proof → contact form → confirmation → enquiry received.
For a hotel:
room page → availability → booking → payment or reservation confirmation.
For ecommerce:
product → cart → checkout → payment → order confirmation → fulfilment record.
The visible design may be 90% complete while the business-critical journey is only 50% complete.
I have seen the same pattern in product work: a screen looking finished tells you very little about whether the transaction behind it is reliable.
If your form says “sent” but enquiries never arrive, for example, that is a separate system failure. See my guide to contact forms that submit but do not deliver the email.
Ask the replacement developer for a takeover audit before a rebuild quote
The next developer should not need weeks to tell you whether the project is salvageable, but they do need enough access to inspect it properly.
A useful takeover audit should answer:
- What currently works?
- What is visibly incomplete?
- What is technically incomplete but hidden from the normal user?
- Which accounts or assets are still missing?
- Is the existing code or CMS maintainable?
- Are there obvious security or dependency problems?
- Are forms, analytics and SEO routes intact?
- What must be stabilized before feature work continues?
- What can be reused?
- What should be rebuilt?
- What is the smallest scope that gets the business to a reliable launch?
That last question matters.
A rescue project can become an excuse to redesign every page, rewrite every sentence and replace every tool. Sometimes that is justified. Often it simply turns a takeover into a larger sale.
The audit should separate required recovery work from optional improvements.
Finish, repair or rebuild: use the economics, not emotion
There are three broad outcomes.
Finish the existing build
This makes sense when the architecture is sound, the important accounts are accessible and the remaining work is genuinely incomplete rather than structurally broken.
Examples include missing pages, unfinished responsive states, incomplete CMS setup, forms that need connecting or final QA before launch.
Repair the weak parts
The site may be usable but have a few risky boundaries: broken forms, poor mobile behaviour, missing analytics, slow pages, insecure configuration or an unreliable deployment process.
In that case, targeted repair can preserve the good work while fixing what actually blocks launch or enquiries.
Rebuild
A rebuild becomes reasonable when continuing the existing work costs more than replacing it or when the current foundation creates unacceptable risk.
That may include a codebase nobody can safely maintain, missing source code, an unsuitable platform, severe security problems, an architecture that cannot support the required business flow, or so much hidden rework that “finishing” is effectively a rebuild anyway.
Do not let sunk cost force you to keep bad work. But do not let frustration make you discard good work either.
If the decision is unclear, my website refresh vs redesign vs rebuild guide gives a broader framework for separating those scopes.
What a website takeover quote should show
A good rescue quote should be easier to audit than the situation you are escaping.
Ask for the work to be separated into clear groups:
| Scope | What it covers |
|---|---|
| Access recovery | Accounts, ownership, repository and missing credentials |
| Stabilization | Backups, urgent errors, security and keeping the current site usable |
| Completion | Work that was in the original unfinished scope |
| Repair | Existing features that are present but broken |
| Improvements | New ideas that are useful but not required to complete the takeover |
| Handoff | Documentation, ownership, training and final access |
Tie payments to inspectable milestones rather than vague percentages such as “website 80% complete.”
If you are deciding what is reasonable to pay before work begins, see how much to pay a web designer upfront.
Do not repeat the ownership problem with the replacement developer
A rescue is also a chance to improve the operating model.
The business should ideally control the core accounts while granting the developer the access required to do the work.
That normally means:
- the domain is registered to the business;
- hosting or deployment is recoverable by the business;
- source code lives in a repository the business can access;
- payment accounts belong to the business;
- analytics and Search Console have business-owned access;
- credentials can be rotated without losing the website;
- important data has a backup path;
- the handoff requirements are written into the scope.
Ownership does not mean the owner must personally operate every technical system. It means the business is not one vanished freelancer away from losing its digital property.
My web design proposal guide covers the ownership, milestones and handoff questions worth settling before the next build begins.
What to send a rescue developer before asking for a quote
You can make the first assessment much faster by preparing a short takeover brief.
Include:
- live website URL;
- what the website is supposed to achieve;
- what you believe is unfinished;
- the original scope or proposal if available;
- screenshots or notes showing the expected design;
- the accounts you currently control;
- repository access if available;
- the most urgent business problem;
- whether the current site is live, broken or still private;
- your desired launch deadline.
Do not paste passwords or secret keys into an ordinary enquiry form. State which systems you can access and share credentials later through an appropriate secure method after the engagement is established.
The objective is a controlled takeover, not another leap of faith
When a developer disappears, the immediate fear is that all the money already spent has been lost.
Sometimes substantial work really does need replacing. But you cannot know that from silence alone.
Recover the assets. Preserve the current state. Test the business-critical journeys. Get the existing work audited. Then pay for the smallest responsible path from unfinished to reliable.
If you have an unfinished business website and need someone to determine what can be saved, what needs fixing and what it would take to get it live, see my web design service or send me the project details. I can start from the current state rather than assuming you need to pay for everything again.
