What happens if your only developer leaves?

The question most businesses avoid

Plenty of businesses have one person who really understands how their software works. Sometimes it’s a founder who built the first version. Sometimes it’s a long-serving developer who has been there since the beginning. Sometimes it’s a freelancer or agency contact who has quietly become essential without anyone deciding they should be.

Engineers have a slightly grim name for this: the “bus factor”. It’s the number of people who would have to be hit by a bus, or more realistically, resign, fall ill, or go on a long holiday, before your product stalls. If the answer is one, you have a problem, even if everything is running smoothly today.

Why it’s a business risk, not just a tech one

Everything waits on one person

When one person holds all the knowledge, every decision routes through them. Bug fixes, new features, answers to customer questions: all of it queues up behind one calendar. The business can only move as fast as that person can, and they can’t take a proper break without things grinding to a halt.

Leaving becomes a crisis, not an inconvenience

People leave jobs. That’s normal, and it shouldn’t be a disaster. But if the person walking out of the door is the only one who knows how your systems fit together, where the passwords are, and which parts are held together with workarounds, their notice period becomes a frantic scramble to extract what’s in their head. Some of it always gets lost.

It shows up in due diligence

If you’re raising money or selling the business, investors and buyers will ask about this directly. “What happens if this person leaves?” is one of the standard questions in technical due diligence, and “we’d be in trouble” is an answer that can affect the price, the terms, or whether the deal happens at all. Larger customers increasingly ask the same thing before they sign.

It’s hard on the person, too

It’s easy to forget, but being the only one who knows how things work is exhausting. The person carrying it is often the one who gets called on holiday, who can’t be ill at a bad time, and who never gets to work on anything new because they’re always holding the old things together. That’s how you lose good people.

How to tell if you have this problem

You don’t need to be technical to check. Ask yourself, or your team, a few plain questions:

• Could someone else fix a serious problem at 9pm on a Friday if your main developer didn’t answer their phone?
• Is anything written down about how your product is built, deployed and looked after, or does it all live in one person’s head?
• Does anyone else review changes before they go live, or does one person write and release everything?
• Who has the logins to your hosting, domains and key services, and would you be locked out if they were unavailable?

If most of the answers point at the same name, your bus factor is one.

How to fix it without drama

The good news is that reducing key-person risk isn’t expensive or disruptive. It’s mostly habits, and none of them require anyone to be pushed out or replaced.

Make sure changes get a second pair of eyes

Having every change reviewed by someone else before it goes live is the single most effective fix. It catches mistakes, but more importantly it means at least two people understand every part of the system, gradually and without anyone setting aside time for “knowledge transfer”.

Write the important things down

Not an encyclopedia. A clear overview of how the product fits together, how to release it, and what to do when common things go wrong. Enough that a capable new person could get useful in their first couple of weeks rather than months.

Get the keys out of one person’s pocket

Access to hosting, domains, code, and paid services should belong to the business, not an individual, with at least two trusted people able to get in. This one is quick to do and is often the scariest gap when it’s missing.

Hire, and hire for ownership

Eventually the real fix is more people. When you do hire, look for people who can take genuine ownership of parts of the product, not people who will need the existing expert to check all of their work. I’ve written about hiring your first engineers without a technical background if that’s where you are.

What it looks like when it’s fixed

I worked with a founder who had built his whole product alone and couldn’t step away from it for a day. After a few months of hiring, code review, documentation and some simple decision-making habits, he could go on holiday and come back to find bugs fixed and features shipped without him. You can read how that went in the case study.

In one line

If one person leaving would stall your product, that’s not a staffing detail, it’s one of the biggest risks in your business, and it’s one of the cheapest to fix before it becomes urgent.