What happens to your software when the person who built it leaves

Most owners we meet can tell us, to the week, when their software was built and what it cost. Very few can tell us what happens to it on the Monday after the person who built it stops answering. Not because they are careless — because nothing in the normal course of business ever forces the question.

Then it gets forced. Someone resigns, an agency winds down, a contractor moves country. The software keeps running, which is the part that fools people. It runs until the day it needs to change, and on that day you discover the difference between owning software and merely using it.

This is not a technical problem, and the fix does not need a developer. It needs four things established, written down, and verified by someone other than the person who holds them.

The single most common failure we find is not lost code. It is a cloud account, a domain registrar or an app-store listing registered to a personal email address that belongs to someone who no longer works for you. The software is yours. The keys are not.

Establish this week: every account the business depends on is registered to a company address, billed to a company card, and has at least two people with administrator rights — one of whom is an owner or director. The test is not "can we log in today." It is "can we log in if that one person never replies again."

Write the list down. Hosting, database, domain, code repository, email, payment provider, analytics, any AI or model provider. If a line on that list has one name against it, that line is the risk.

Code tells you what a system does. It almost never tells you why. Why this provider, why the data is shaped this way, why that feature was abandoned halfway, why a particular limit exists. That reasoning is what makes the next change safe, and it usually lives entirely in one head.

You do not need documentation in the formal sense. You need a running log — a page per significant decision, a paragraph each: what we chose, what we rejected, and what would make us revisit it. Ten minutes at the time it happens, worth weeks later.

When we take over an undocumented system, the first month is not spent building. It is spent reconstructing reasoning from evidence, which is slower and less certain than being told.

Ask the question directly: if a small change had to go live next week, what are the steps? If the honest answer is "we ask Arun," you have a person-shaped deployment process. If the answer is a written sequence anyone technical can follow, you have a system.

The specific things to have in place: a repository the company controls, an automated set of checks that runs before anything ships, one command or button that deploys, and a backup you have actually restored from rather than merely configured.

That last distinction matters more than any of the others. A backup you have never restored is a belief, not a capability.

The reason a strong engineer leaving hurts so much is that the standard left with them. Their judgment about what is good enough was never written into anything; it existed as a habit and a set of opinions applied in review.

A standard that survives is enforced by the system rather than by a person: the checks that must pass, the review that must happen, the definition of done that is the same on a busy week as a quiet one. Once that exists, a new person is productive in weeks rather than quarters, because the work tells them how it is done here.

The measure we hold ourselves to is the week after we are gone and nothing breaks. It applies equally to your own team.

None of this requires a project. It requires an afternoon and a willingness to write down uncomfortable answers.

• List every account the business depends on, and note who has admin on each.
• Move anything registered to a personal address into company ownership.
• Ask for the deployment steps in writing, and have someone else follow them once.
• Restore a backup into a test environment and confirm the data is really there.
• Start the decision log with the next decision you make.

If the answers to those five are uncomfortable, that is useful information rather than a verdict. Almost every business we have worked with started from exactly there.