What Happens to Your Website When Your Developer Disappears?

It's the question clients think but rarely ask out loud: what happens to my website if you disappear?

Not because they think you're about to do a runner. Just because they've heard the stories. The agency that went under. The freelancer who stopped replying. The developer who got too busy and drifted, taking all the passwords with them. It's a reasonable thing to worry about, and most developers never bring it up.

So let's actually talk about it.

Who owns the code?

First, the good news: if someone built your website, you almost certainly own it. Unless your contract says otherwise — which you should check, but is rare with reputable developers — the work they did for you is yours.

In practice, though, "owning" the code and being able to do anything with it are two different things. You might legally own every line, but if it's sat in someone else's private repository that you don't have access to, you're not in a great position.

What you actually want is:

• The code in a repository you control. GitHub, GitLab, Bitbucket — any of these work. The important thing is that it's under your account, or at minimum that you have full access to it. Not just read access. Owner-level access.
• The hosting account in your name. Whether that's Vercel, AWS, a shared hosting provider, or a managed server — if you're the account holder, you can always transfer the site somewhere else, change the access, or hand it to a new developer.
• All the credentials. Domain registrar login. DNS access. Any third-party service accounts (analytics, email, CRM integrations). In a password manager you own.

If any of those aren't currently true, it's worth sorting now rather than waiting for a crisis.

What a proper handover actually looks like

A good developer handover isn't just handing over a zip file and wishing you well.

When I finish a project — or when a client is moving to someone else — what gets handed over is:

• Full repository access. The entire codebase, with history. Not just the files, but the record of what changed and why.
• A README that a competent developer can follow. How to set up the project locally. What environment variables are needed. How the deployment pipeline works. Nothing exotic — just the things that take time to figure out if you have to reverse-engineer them.
• All the logins. Hosting, domain, any API keys or third-party services the site depends on. Transferred to the client's own accounts where possible.
• A brief walkthrough. Thirty minutes on a call explaining the architecture, the quirks, where things live. Written up afterwards so it doesn't just evaporate.

It's not glamorous. It's also not optional if you're doing the job properly.

Questions to ask before you hire someone

The time to think about the exit is before you're at it. Here are the questions worth asking:

"Will the code be in a repository I control?" If the answer is no, or vague, that's a red flag. Your code should live in your account.

"Who will the hosting account be registered to?" Ideally you. If it's under the developer's account for billing reasons, make sure you have documented access and an agreed process for transferring it.

"What does handover look like at the end of the project?" A good developer will have an answer. A vague answer ("oh, we'll sort all that out") is worth pushing on.

"Do you have previous clients I could speak to?" Not just about the work quality — about what happened after. Did things keep running? Was the handover smooth?

None of these questions are rude. Any developer who's bothered by them isn't someone you want to work with.

Locked in vs. set up well

There's a meaningful difference between a developer who's made themselves hard to leave and one who's made themselves good to work with.

Being locked in looks like: proprietary systems that only they understand, logins you don't have, a codebase with no documentation, hosting and domains under their accounts, dependencies on tools they resell at a margin.

Being set up well looks like: standard tools and frameworks, clear documentation, everything in your name, and a developer who'd rather you come back because you want to than because you have no choice.

I'd rather have clients return because the work is good and the relationship is easy. That means making sure they can leave if they need to.

After thirteen years, I've seen both versions play out. The developers who lock clients in don't tend to last — word gets around. The ones who make it easy to move on, if it comes to that, are usually the ones people actually stick with.

---

Worried about your current setup? Get in touch — a quick audit of who owns what can save a lot of stress down the line.