Your developer stopped replying. Maybe it was gradual — slower answers, then none. Maybe they took a full-time job, moved, got sick, or simply decided they were done. It happens constantly, and it is not a sign that you did anything wrong.
Here is the uncomfortable part. Your system is still running, taking orders and holding customer records. It looks fine. And the only person who knew how it fits together is unreachable.
Nothing bad happens on the first day. That is exactly what makes this dangerous.
What actually changed
Software does not stop working when its author leaves. It keeps doing what it was told to do, indefinitely. What you lost is not function. You lost the ability to change anything.
Three things quietly became true the day they stopped answering:
Nobody can make a fix. Not because the work is impossible, but because no one knows where anything is. A change that would have taken your developer an hour now takes a stranger three days, because they must first work out what they are looking at.
Nobody is applying security updates. The language your system is written in, and the pieces of other people’s code inside it, get security fixes for a few years and then stop. Somebody has to install those fixes. That person left.
Nobody would notice a problem before your customers do. Most small systems have no alarm on them. If it goes down at 2am on a Saturday, it stays down until someone calls you.
The first thing to do, before anything technical
Find out what you own.
This is not a developer task. You can do it this afternoon, and it matters more than any code.
Make a list of every account your business depends on, and check who controls each one:
- Your domain name — where yourcompany.com is registered. If this is in your developer’s name or on their card, it is the single most urgent item on the list. Losing a domain takes your website and your email at the same time.
- Your hosting — the server the system runs on. Whose account, whose card?
- Your code — a copy of the actual software, usually on GitHub, GitLab or Bitbucket. Sometimes it exists only on the server.
- Your email service, payment processor, text-message service — anything with a monthly charge.
- Your DNS — the settings that point your domain at your server. Often a separate account from the domain itself.
For each one, you want two answers: whose name is it in, and whose card pays for it. Anything not in your name and not on your card is a thing you do not currently own.
Do not change passwords yet. If your developer might still respond, an abrupt lockout ends that conversation. Get the picture first.
What to do about the code
If you can find the repository — the place the code is stored and its history kept — get an invite to it as an owner, today. That history is worth more than it looks. It is a record of every change made to your system and why, and it is how a new developer catches up in a week instead of a month.
If you cannot find it, the code still exists on the server that runs your site. It can be pulled down. What is lost is the history, which makes the next developer’s job slower but not impossible.
The version of this that ends badly is the one where the code lives only on a laptop you cannot reach. That is rare, but it happens, and it is a reason to check now rather than later.
Then find out what you are actually running
You do not need a developer to start this. Open a support ticket with the hosting company and ask two things in writing: which versions the account runs, and when each stops receiving security updates. Hosting support answers that in a day, it costs nothing, and it tells you roughly how old the software underneath your site is.
That gives you the outside view in two minutes. It will not tell you whether one order in four goes missing, or why the connection to your accounting system fails every Tuesday. Only reading the code answers that.
What a proper look involves
The full picture takes about five days of someone reading your system carefully: the code, the server it sits on, and the history of changes if any survives. What comes out is a written document in plain language covering what you have, what is dangerous, what it would cost to fix, and which items are actually costing you money right now versus which are theoretical.
You own that document. If you decide to hire someone else, or your original developer resurfaces, you hand it to them and they are immediately useful. It is not a sales artifact. It is the thing that makes you no longer dependent on any one person’s memory — including ours.
That audit is $2,400, fixed, and the fee comes off the cost of the work if you go ahead. If the answer is that your system is in decent shape, you get that in writing too. See what everything costs before you talk to anyone.
What this is not
This is not an emergency that requires you to make a decision this week. Your system will keep running. The reason to act now is that every month without maintenance makes the eventual work slightly larger and slightly more expensive, and because the recovery of accounts gets harder the longer a developer is unreachable.
It is also not a rebuild. Rebuilding is what gets sold to owners in this position, and it is usually the wrong answer. Your system knows how your business works — which discounts apply to which customers, which edge case in your ordering process exists because of one client in 2019. That knowledge took years to accumulate and is not written down anywhere else. The job is to replace what has rotted underneath it while keeping all of that intact.
You are not in a crisis. You are in a situation that gets worse slowly, and the fix is cheapest at the beginning.