What Do I Do If My Web Developer Is Unresponsive?

A practical path for companies that need to regain control and finish the work with a new firm

It is more common than most business owners admit. A developer is hired, deposits are paid, work starts, and then communication slows. Deadlines slip. Updates become vague. Then the inbox goes quiet. The site is half-built, the accounts may not be in the company’s name, and the original schedule is no longer real.

The project is usually recoverable. The mistake is spending weeks chasing someone who has already checked out. The faster a company secures what it owns, documents the gap, and brings in a firm that finishes other people’s work, the less money and time get written off.

1. Stop chasing. Start documenting.

Send one clear, professional final notice. State the outstanding work, the last date you heard from them, and a short deadline to respond and hand over files and credentials. Then stop. Keep every email, invoice, proposal, chat log, payment receipt, and screenshot of the current site. That file becomes the paper trail for a hosting or domain dispute, a contract review, or a handover to the next team.

If a written contract exists, read it before you terminate anything. Look for ownership of code and content, who holds the domain and hosting, notice-and-cure periods, and what happens to unfinished work. Ending the relationship the wrong way can create a second problem. If the dollars at stake are material, have an attorney look at the agreement before you send a termination letter.

2. Secure the assets that cannot be rebuilt.

Code can be rewritten. A lost domain cannot. Work in this order:

  • Domain registrar. Confirm the account is in the company’s name, change the recovery email and password, turn on two-factor authentication, and lock the domain. If the developer registered it, contact the registrar with business registration, invoices, and correspondence. Registrars have processes for this.
  • Hosting and DNS. Recover the control panel, download a full backup of files and the database if you can, and move billing to a company card. If the site lives under the developer’s account, plan a migration to hosting you control.
  • Code repository. Clone or download the repo. If you have admin rights, revoke the old developer’s write access. If the repo sits in their personal GitHub or GitLab account, fork or copy it immediately.
  • CMS, email, payments, analytics, and APIs. Rotate every password and API key. Remove unknown users. Confirm Stripe, email, CRM, and similar tools are billed and owned by the company, not the vendor.

If you still have any access at all, take a backup before you change anything. A live site with no one maintaining it is a security risk, not a holding pattern.

3. Get an honest picture of what exists.

Do not ask a new firm to “just finish it” until someone has looked under the hood. A short technical audit should answer four questions: what works, what is incomplete, what is insecure or undocumented, and whether it is cheaper to repair the current build or salvage content and rebuild.

Most stalled sites fail on missing credentials and unwritten decisions, not on exotic code. The first deliverable from a rescue firm should be a written gap list and a realistic path to launch — not a promise to honor the original deadline. That deadline is gone. The useful question is: given what exists today, what is the fastest responsible way to get a working site the company owns?

4. Bring in a firm that takes over unfinished work.

Finishing someone else’s project is a different job than starting from a blank page. Look for a partner that will:

  • Put every account in the company’s name before they write new code.
  • Work from a written assessment with a fixed or capped scope, not an open-ended hourly sink.
  • Build and test in staging, not directly on the live site.
  • Hand back documentation, repository access, and admin credentials at launch — not “after final payment someday.”

Expect to pay for time that is not visible: reading the old code, mapping integrations, and testing assumptions. That audit time is usually cheaper than rebuilding from scratch and discovering later that half the original work was usable.

5. Close the loop on money and risk.

Whether you pursue a refund, a credit, or simply walk away depends on the contract, the amount paid, and whether the developer delivered anything usable. Small-claims court exists for modest sums. For larger amounts, a demand letter from counsel is often the first move. Many companies decide the cost of litigating is higher than the cost of finishing the site and treat the lost deposit as tuition.

Either way, do not let the legal question freeze the website. The business cost of an unfinished site usually grows faster than the recoverable dollars.

6. Do not hire the next partner the same way.

The pattern that creates ghosted projects is predictable: vague scope, accounts opened in the developer’s name, no repository the client owns, and no written definition of “done.” The next agreement should put the domain, hosting, and code repository in the company’s account from day one, require regular working demos rather than status emails, and spell out handover if the relationship ends. Ownership at the start is easier than recovery at the end.

Bottom Line

Secure the domain and accounts. Document the work and the silence. Audit what is actually there. Then hire a firm that specializes in taking stalled projects across the finish line, with the keys in your name when they are done. The original developer may never reply. The site can still launch.

Facebook
Twitter
LinkedIn

To be taken to the next page