What happens when your developer disappears, and how to prevent it
Freelancers move on, agencies fold, people stop answering. What breaks first when that happens, how to recover, and the five things that make it a non-event.
The short answer
It happens: a developer stops answering. Freelancers take jobs, agencies close, people move on. It happens to businesses every week, and the damage depends entirely on one question: does the business own and control its own website, code, domain, hosting and accounts? If yes, the departure is an inconvenience handled in an afternoon by whoever comes next. If no, it is weeks of written requests and a formal complaint, rebuilding from the public site and resetting every credential, while renewals lapse and forms fail. Prevention costs almost nothing and is usually skipped.
What breaks first, and when
| Time after departure | What happens | Why |
|---|---|---|
| Immediately | Nothing visible; the site works | Static assets and hosting keep running on their own |
| First change needed | Nobody can edit anything | Code and admin access were theirs |
| First incident | A form stops delivering or an error appears; nobody is alerted | Monitoring, if any, alerted them |
| First renewal | Hosting, domain or certificate lapses | Paid from their card, registered in their name, reminders to their inbox |
| A security event | Nobody applies the patch; the site is compromised | Updates were their job |
| Months later | Search rankings drop; email bounces | Accumulated neglect |
Recovery, if it has already happened
- Inventory what you can reach. Log in to everything you have credentials for: registrar, hosting, analytics, email. Note what you cannot reach.
- Secure the domain first. It is the asset everything depends on. If it is in your account, turn on auto-renew and a lock. If it is in theirs, put the transfer request in writing today, with a deadline.
- Get a copy of the code, from the repository if you can reach it, from the host if not, from a crawl of the live site as a last resort.
- Reset every credential you regain, and set up two-factor. Assume the departed party still has the old ones.
- Set up monitoring so the next failure alerts someone who exists.
- Decide: hand over or rebuild. A new partner assesses what was recovered. The question is not only price but what you end up holding: a rebuild on an owned, documented stack leaves you with code, history and documentation a successor can use, where resuscitation often leaves the same gaps in place.
Prevention: five items
- Every account in the business’s name, on a company email that several people can access, with the business’s payment method.
- Code in the business’s own repository, with the developer as a collaborator, not the owner.
- A current one-page document describing the setup: what runs where, how to deploy, which services are involved, who to call.
- A second person with access, inside the business, with two-factor, who logs in once a quarter to prove it still works.
- An exit clause in every agreement describing hand-over: what is delivered, in what form, within what time.
What this means for you
Your developer will leave one day, on good terms or none. Whether that matters is decided now, by whose name is on the accounts, where the code lives, whether the setup is written down, and whether someone besides them can log in. Five cheap items. Check them this week, and the departure, when it comes, is an afternoon’s work for whoever comes next.
Frequently asked questions
Our developer has gone quiet but the site still works. Is there a problem?
Not today. The problem arrives on the renewal date of whatever is in their name, or the day you need a change. Use the quiet time: find out what is registered where, get access moved to your accounts, get a copy of the code, and document the setup. Do it before the next renewal, not after.
The domain is registered in the developer's name. Can we get it back?
Sometimes, and the first question is which extension. A .nl domain falls under SIDN's dispute regulations, which cover trade names as well as trade marks and open with thirty days of free mediation. .com and other gTLDs fall under the UDRP, which requires a trade mark right. What does not exist is a registrar deciding who should own a name: their dispute procedure settles arguments between registrars. Otherwise it is a negotiation or a court case, and both take months. Far cheaper is to have the domain transferred while the developer is still cooperative.
We have no code and no access. Can a new partner rebuild from the live site?
Yes. The public site can be crawled: content, images, structure and styling. What cannot be recovered that way is anything behind a login, form logic, integrations and the database. A rebuild on a modern stack is often the right answer anyway, but it is a project, not a handover.
Sources
- ICANN: Registrar Transfer Dispute Resolution Policy (accessed 2026-09-14)
- ICANN: Uniform Domain Name Dispute Resolution Policy (accessed 2026-09-14)
- WIPO: Dispute Resolution Regulations for .nl Domain Names (accessed 2026-09-14)