← Blog/Process··10 min read

Your Web Developer Disappeared: The Recovery Plan

Your web developer disappeared and nobody is answering. Start with the domain registrar, not the website — the full access inventory and recovery order.

G
Written by
Graham Sissons · Founder, Pryce Digital

The third unanswered email is the one that changes the temperature. The first two get written off as a busy week. Then the mobile goes to voicemail, and someone says out loud what everyone has been thinking: we don't actually know where our website lives.

It happens more often than the industry admits, and not always because anyone behaved badly. Developers retire, take a full-time job and stop answering, fall out over scope, get sick, die. The outcome from where you're standing is identical: there's a business asset you depend on, and the only person who knew how to get into it is gone.

The instinct is to panic about the website. That's the wrong order. The website is the least urgent thing on the list — it's still up, it's still serving pages, and worst case it can be rebuilt. What can't be casually rebuilt is the domain name, and after that the email running on it. Work outwards from those two and most of these situations resolve inside a fortnight; work inwards and you'll burn a month on the part that mattered least.

Hour one: establish what you actually control

Before you contact anyone, find out what's already in your name. Most owners hold more than they feared and less than they assumed. The test isn't "do I know this exists" — it's "can I log in right now, with a password reset that lands in an inbox I control."

DOMAIN
The crown jewel
Who is the registrant of record, and which registrar holds the licence. Everything else here can be replaced. Losing this costs you your address, your email and the search equity attached to both.
DNS
The switchboard
Whoever controls DNS controls where your site and mail point, regardless of who owns either. Often not the registrar — plenty of developers move DNS to Cloudflare or a hosting panel.
EMAIL
The one with a clock on it
Google Workspace or Microsoft 365 admin access, plus the mailbox data. If the tenancy was created under the developer's account, that's a live operational risk, not a filing problem.
HOSTING
Where the files sit
The server, the platform account, the database. Check whose card renews it — that answers the ownership question faster than paperwork.
CODE + CMS
Replaceable
The repository, the admin login, the content. Painful to lose, genuinely recoverable, never a reason to delay the three above.
SATELLITES
Not this week
Search Console, Analytics, Google Business Profile, the payment gateway, the booking system. Each has its own recovery path, and none are urgent yet.

Write the answers into a shared document, not one person's inbox — you'll be repeating this list.

The domain: who holds the licence

A .au domain isn't property the way a van is property. It's a licence issued under rules administered by auDA, and it belongs to the registrant — the entity named on it. Not the registrar who sells it, and not whoever filled in the form. Eligibility is assessed against the registrant too: a .com.au needs an Australian presence and a genuine connection to the name, and that test applies to whoever is named, not whoever paid the invoice.

Run a WHOIS lookup. For .au names the registrant's name and ABN or ACN are public, even though contact details are redacted. Three outcomes.

Your business and ABN are on the licence. You're in good shape. Contact the registrar, prove you're the registrant, reset the account access and ask for the transfer password so you can move the domain somewhere you control. Their obligation runs to the registrant, not the agency paying them.

The developer's company is on the licence. This is what people mean by a website being held hostage, and it needs a change of registrant rather than a transfer. If they're contactable but slow, it's paperwork. If they've gone dark, your position is that their claim to a name matching your business is thin — registrants need a close and substantial connection to the domain, and "we built them a site once" isn't much of one. Registered business names and trademarks strengthen that, which is a good reason to hold both. auDA also runs a dispute policy, the auDRP, for this exact class of disagreement.

Nobody can tell. The registrant is a trading name you don't recognise, or an ABN belonging to a deregistered company. Search both on the ASIC registers first. A deregistered company changes the conversation, and a sole trader who has died means dealing with an executor.

We've written separately on how .com.au ownership goes wrong in the first place — the piece to act on if nothing has gone wrong yet.

Email is the emergency with a deadline

Domain first, email straight after: mail failure is what customers notice within hours. Two things can break. Your MX records are a DNS setting, so whoever controls DNS can redirect your mail — and if that account lapses unrenewed, delivery stops with no warning. Separately, if your Google Workspace or Microsoft 365 was created under the developer's account with their address as super administrator, that's someone else's asset holding your correspondence.

For both providers the recovery path runs through domain ownership: publish a verification record in DNS to prove you control the domain, and there's a route back to administrative control. One more reason the domain outranks everything else here.

While that's in motion, export mailboxes locally for whoever would be worst affected, and put at least one contact address on your site that you definitively own. A monitored Gmail address on the contact page for a fortnight isn't a good look. It beats enquiries vanishing.

What you can rebuild without them

Here's the part that reframes the situation. Under Australian copyright law the developer generally owns copyright in code they wrote unless there's a written assignment. Owners hear that and assume they're trapped. They almost never are.

That copyright covers the specific code. It doesn't cover your business name, logo, photographs, written content, customer data, domain, Google Business Profile, or the idea of a site that does what yours does. A rebuild puts your content on your domain with a new codebase, and there's nothing in that sentence a departed developer has a claim over. The contract clauses that govern this are worth understanding, particularly if there's a chance they resurface.

Which leads somewhere uncomfortable but usually correct: chasing a silent developer for a codebase you can't read, can't maintain and didn't much like is a worse use of three months than building the replacement. The exception is substantial custom functionality — a booking engine, a quoting tool, a job-management integration — where the code carries real value and the rebuild carries real cost.

The website you're fighting to recover is frequently the website you were about to replace anyway. That changes what the fight is worth.

When you're genuinely stuck

Three situations are properly hard rather than merely irritating.

The registrant is their entity and they've gone dark. Registrar dispute processes and the auDRP both exist, both take time, and both work better with evidence — invoices, emails, a registered business name, a trademark. Start collecting now, not when someone asks.

The hosting sits on their account with no export. If the account is in their name the host won't hand it over, and shouldn't. But your public site is still on the internet: crawl it, save the pages, pull the images at full resolution. Anything public is recoverable with a browser. A database of customer records behind a login is not — which is why the export you keep meaning to schedule matters more than the code.

There's a live payment or booking integration. Those platforms hold their own accounts with their own recovery processes, usually tied to the business identity rather than the developer's. Contact them early, and don't cut DNS across until you know what breaks.

If money is owed and the work was never delivered, that's a contract matter rather than a technical one — the ACCC sets out where small business protections apply. Our honest read: most owners recover faster by writing off the relationship and spending the energy on the replacement, not the argument.

Migrating without their cooperation

Assume no handover and no goodwill. The sequence still works.

Get the domain into an account you control first, then think about the site. Take a full copy while the old one is up — every page, every PDF, every image — because the day hosting lapses isn't announced in advance. Keep your URL structure identical unless you have a reason not to; changing addresses mid-emergency is how a recovery becomes a rankings problem. Lower your DNS time-to-live a day before cutover. And confirm your MX records survived before you go home: a site that's briefly wrong is embarrassing, email that's silently broken is expensive.

Then treat the new build as a build, not a rescue. Our small business website development work starts at $8,000 AUD, and the strongest position to commission from is exactly the one you've just secured — holding your own domain and your own content, and not doing this twice.

The access matrix to hold from now on

Prevention is one page and forty minutes. The rule: accounts representing your business are created by your business, and suppliers are given access. Never the reverse.

ALWAYS IN YOUR NAME

  • Domain registrarOwner
  • DNS providerOwner
  • Workspace / M365Owner
  • Search ConsoleOwner
  • Payment gatewayOwner

FINE FOR THEM TO RUN

  • Hosting accountExport rights
  • Code repositoryYou hold admin
  • CMS adminYou hold admin
  • Build toolingTheirs
  • Staging siteTheirs

Add one recurring calendar entry: once a year, log into every account in the left column yourself. Not your marketing manager, not your agency. Ten minutes confirms the credentials work and the recovery email still reaches you. Our website handover checklist covers what to demand at the end of a project — the point where every item in that left column should land in your hands, documented.

FAQ

Can my web developer hold my website hostage?

They can make it difficult, but the leverage is narrower than it feels. If the domain licence is in your business's name, a developer can't stop you moving it — the registrar's obligation runs to the registrant. What they can do is sit on hosting, code and CMS access, and decline to hand over files they hold copyright in. That's usually cheaper to route around than to fight, because the content, domain and brand are yours.

How do I find out who owns my domain name?

Run a WHOIS lookup on your domain. For .au names the registrant's name and their ABN or ACN are published, so you can see immediately whether the licence sits with your business or someone else's. Contact details are redacted, but the registrant identity is the part that matters. If the name isn't yours, fix that first — ahead of anything to do with the website.

Can I rebuild my website if the developer owns the copyright?

Yes, in almost every ordinary case. Copyright in the code doesn't extend to your business name, logo, photos, written content, customer data or domain. A new site built from your own content by a different studio isn't a copy of their work. Care is needed only around bespoke functionality — a custom booking engine or integration — worth a lawyer's read before you replicate it closely.

What happens if my web developer has died?

Their business assets, including any domains registered in their name, form part of the estate, so you'll be dealing with an executor rather than a company. Be patient and be specific: a written list of the exact accounts and domains, plus your invoices, makes it a straightforward administrative task for someone handling a great deal at once. Meanwhile, secure everything already in your own name.

Start with the two checks that matter

Today, do two things. Run a WHOIS lookup and find out whose name is on the domain licence. Then log into your registrar and DNS provider and confirm a password reset lands in an inbox you control. Fifteen minutes, and you'll know whether this is an inconvenience or a real problem.

If the site is still up and you're weighing recovery against replacement, run it through our free audit first. It won't tell you who owns the domain, but it will show you what the performance, structure and search surface actually look like — often the deciding factor between rescuing something and putting the money into the version you wanted anyway.

If you'd rather talk it through, book 20 minutes or call us on 0421 933 907. Bring the domain name and whatever logins you've found — enough to work out quickly whether you're stuck or merely inconvenienced. The answer is better news more often than owners expect.

END OF POST

Want this for your business?

Get a free instant audit of your current site, or book a 20-minute call to talk through what you're building. No sales pitch.

Free auditBook a call
Or email studio@prycedigital.com
Keep reading
Warning Signs Your Website Build Is Going SidewaysProcessThe Website Handover Checklist Agencies Hope You SkipProcessWho Writes Your Website Copy? Decide Before You BuildProcess
Explore our services
Custom Web Design Melbourne — hand-coded sites built from scratchWebsite Development for Small Business — the full breakdownWeb Design Melbourne — why local matters
← Back to blog indexFree audit