The instinct is to find a new developer immediately. That is the wrong first move, and it costs money.
Here is a better order. Most of week one is not technical, and you can do it yourself.
Days 1–2: Establish what you own
Before anyone looks at code, find out which accounts are actually yours. Go through your bank statement line by line and write down every recurring charge connected to the business’s software. That list is a reliable map of what you depend on, and it will surface services nobody remembered signing up for.
For each one, establish two facts: whose name is the account in, and whose card pays for it.
The order of urgency is not obvious, so here it is:
- The domain name. If this is registered in your developer’s name, it is the most urgent item you have. Losing a domain takes your website and your company email at the same time, and recovering it through a registrar’s dispute process takes weeks.
- DNS. The settings that point your domain at your server. Often a completely separate account from the domain registration, and often overlooked.
- Hosting. The machine everything runs on.
- The code repository. Sometimes it does not exist and the code lives only on the server.
- Everything else — payment processing, email delivery, text messaging, error reporting.
Anything not in the company’s name and not on the company’s card is something you do not currently control.
Do not change the passwords yet
This feels wrong, and it is still correct.
If there is any chance your developer will respond, an abrupt lockout ends that conversation permanently. What is in their head is worth more than the small risk of leaving access in place for another week — assuming you parted on non-hostile terms and there is no reason to suspect malice.
If there is such a reason, that changes the calculation entirely and you should lock everything down today.
Days 2–3: Send one specific email
General requests get postponed. Specific ones get answered.
Do not write “can we schedule a call to hand things over”. Write a numbered list:
- Which registrar is the domain at, and what is the account email?
- Where is the code, and can you add [your address] as an owner?
- Which hosting company, which account?
- Is there a list anywhere of the other services the system uses?
- Who else has worked on this?
Five questions somebody can answer in ten minutes get a far better response rate than an open-ended request for their time. Keep the tone neutral. You want information, not an accounting of why they stopped replying.
Day 3: Get the outside view
You do not need a developer for this part.
Public records will tell you a surprising amount about what your system is running — the server software, roughly which version of the underlying language, whether a protective layer sits in front of it, and whether those versions still receive security fixes. Servers announce this to anyone who asks, and it is indexed publicly. It is also how an insurer or a customer’s IT department would find out.
You can get the same answer faster and in more detail from the hosting company itself: open a ticket and ask which versions the account runs and when each stops receiving security updates. Whatever comes back, you now know something concrete instead of nothing.
If it comes back saying your server software is years past its support date, that is worth understanding properly rather than panicking about. Here is what that situation actually looks like from the inside, including the part where the disk was three weeks from filling up and nobody knew.
Days 4–5: Secure the code
If you found the repository, get yourself added as an owner immediately and confirm you can see the full history. That history is worth more than it looks — it is a record of every change ever made and, if the previous developer wrote decent notes, why. It turns a new developer’s first month into their first week.
If you cannot find the repository, the code still exists on the server that runs your site and can be retrieved from there. What is lost is the history. That makes the next person slower but it is not fatal.
The version of this that goes badly is when the only copy is on a laptop you cannot reach. It is uncommon, and it is a reason to check now rather than in three months.
While you are there, ask one more question, because it is the one that outlives the handover: are there passwords written inside the code itself? If there are, they are also in every copy of that code anybody ever made, including your former developer’s laptop. That is a specific piece of work with a specific shape, and the fix that matters is not deleting them — it is changing them.
What not to do in week one
Do not hire somebody to rebuild it. This is the most expensive mistake available to you and it will be proposed. Your system encodes years of how your business actually works — the pricing exception for one large customer, the workaround for a supplier’s file format, the step that exists for a regulatory reason nobody remembers. Rediscovering all of that takes eighteen months, and you will find each piece in production.
Do not panic about security yet. If the versions come back years out of support, that is worth acting on — but on a timescale of weeks, not hours. Nothing about your situation changed the day your developer stopped answering. You simply found out about it.
Do not hire the first available developer to “have a look”. Without a map, they will spend billable weeks building one, and you will pay for the same exercise again with the next person.
Week two
Once ownership is secured and you know roughly what you are running, the question becomes whether to get the system properly mapped. That is five business days of somebody reading the code, the server and the history, ending in a written document in plain language: what exists, what is dangerous, and what each fix would cost.
The reason that document matters more than any individual fix is that it is the thing that makes you no longer dependent on one person’s memory — including the memory of whoever writes it. You own it, and any developer you hand it to is useful on day one.
What that costs is published here, along with everything else.