If Your Only Developer Quit Tomorrow

Most companies I get called into are not in a crisis when they call. They are in the quiet period a few weeks after one — the developer who built everything has left, nothing has caught fire yet, and nobody wants to touch anything in case it does.

It is a bad position, but it is a recoverable one. What makes it worse is that almost everyone's first instinct is to hire a replacement immediately and hand them the login details. That is the expensive path, and it is avoidable.

Here is what I would do first, in order. None of it requires you to be technical, and all of it makes whoever you hire next significantly cheaper.

1. Confirm the backup actually restores

Not that backups are running. That a backup can be turned back into a working system.

These are different things, and the gap between them is where companies lose years of data. Backups fail silently all the time — a storage account fills up, a permission changes, a job stops running and nobody notices because nobody is watching for silence. The dashboard says green because the dashboard is only reporting that the last attempt did not error.

The test is simple to ask for and hard to fake: have someone restore last night's backup into a separate environment and open it. If nobody can do that within a day, you do not have backups. You have a folder of files that you believe are backups.

Do this one first. Everything else on this list can wait a week. This one cannot.

2. Write down every outside service your system depends on

Payment processing, email delivery, SMS, file storage, mapping, document signing, whatever else. For each one, you want two facts: which account it belongs to, and whose credit card is on it.

This is the single most common cause of sudden outages in small companies, and it has nothing to do with code. A card expires. An account was in the departed developer's personal name. A free tier quietly ends. The system stops working on a Tuesday morning for a reason that has no relationship to anything anyone changed.

You do not need to understand what any of these services do. You need to know they exist and that you control them.

3. Find out whether anyone else can deploy

"Deploy" means: take a change and put it into the live system your staff and customers use.

If the answer is that only the departed developer could do it, or that it happened from their laptop with a script nobody else has seen, that is your actual emergency — more urgent than the code itself. It means that until it is fixed, nothing can be changed at all, including an urgent fix.

Ask directly: if we needed to correct a typo on the invoice template today, who does that and how? The quality of the answer tells you a great deal.

4. List the three things that break most often

Ask the people who use the system every day, not the technical ones. They will know immediately. Something times out on Monday mornings. A report has to be run twice. A particular customer record cannot be edited without an error.

This list is worth real money. When you hire someone, the difference between "here is the codebase, get familiar with it" and "here are the three things that break, start there" is often weeks of billable time. It also gives you a way to judge the new person quickly: if they cannot make progress on a problem your staff can describe in one sentence, you have learned something early and cheaply.

The instinct that costs the most

At some point, whoever you bring in will suggest rebuilding it.

Sometimes that is the right call. Usually, at this moment, it is not — and it is worth understanding why the suggestion comes up so reliably. Reading someone else's system is genuinely unpleasant work. Rebuilding is more enjoyable, easier to estimate optimistically, and lets the new person work in tools they prefer. The recommendation is often sincere and still wrong.

The part that gets underestimated is that your current system contains years of accumulated business rules that nobody wrote down. The odd exception for one large client. The rounding decision that came out of an argument with your accountant in 2022. The extra approval step added after something went wrong once. None of that is in a specification. It is in the code, and it will be silently dropped in a rebuild — then rediscovered one complaint at a time over the following year.

A rewrite of a system nobody currently understands takes longer than the estimate essentially every time, because the estimate is based on the visible features rather than the invisible rules.

If someone proposes a rebuild in the first month, that is not a technical opinion yet. It is an opinion formed before they know what the system does.

What to do this week

If you do nothing else: test the restore. It is the only item on this list where the downside is permanent.

After that, the other three are an afternoon of asking questions and writing the answers into a shared document. That document is the thing you hand to the next person you hire — and having it is usually the difference between paying someone to learn your system and paying someone to fix it.

None of this requires hiring anyone. It requires deciding that the situation is worth an afternoon before it becomes worth a quarter.

Related reading: Nobody Is Reviewing Your Developer · You Shipped an MVP With AI. Six Things Break Next.

---

If you are in that quiet period right now and would rather have someone walk through these four checks with you, that is a fixed-scope piece of work I do before anyone touches the code - book a 30-minute call and I will tell you honestly whether you need me.