What happens to your software if whoever wrote it disappears

It happens more often than people think: the developer shuts up shop, the supplier changes trade, the person who knew how it worked leaves. And the system the company runs on becomes a box nobody can open.

It is a real risk and nobody puts it in the quote, because it is awkward to name while signing. Four things reduce it.

1. The keys in your hands

Domains, hosting, mailboxes, external service accounts, archives: in your name, with the credentials in your possession, from day one. Not “I will give them to you when we finish”: from day one.

It is the easiest thing to get and the one that makes the most difference. If you have access to the infrastructure, another supplier can take over in days. If you do not, it can take a month just to work out where everything is — and sometimes it is not recoverable at all.

2. Exportable data

Ask to see, before signing, how the data is exported into a format another program can read. Not a proprietary format: a CSV, a SQL dump, a JSON file.

If the answer is “that is not provided for”, you already know the relationship runs one way.

3. A document explaining how it is built

You do not need a hundred-page manual. You need five things written down: where it runs, which external services it uses, how to get in during an emergency, how the code is organised, what needs updating periodically.

Anyone who writes software properly already has that document, because they need it themselves first. Asking for it is an indirect way of learning how they work.

4. Code that can be read

This one you cannot verify yourself, and it is the only one of the four that takes trust. But you can ask a question that says a lot: “if another developer has to work on this in three years, how long before they understand it?”

Anyone answering “it is all documented in the code” is answering well. Anyone answering “we will still be here” is answering a different question — and that may be exactly the point.

The distinction about ownership

It needs settling up front, because it causes misunderstandings: the data and the infrastructure are yours, always. Ownership of the source code is another matter, and it often stays with whoever wrote it unless bought outright — what you are given is the right to use it.

That is neither right nor wrong in itself: it is a contractual condition, and as such it belongs in writing before starting rather than being discovered afterwards. A supplier who explains it without being asked is a good sign.