The fear that stops a lot of businesses commissioning bespoke software. What you need to hold so a system survives losing its developer, and what to do if yours has already gone.

It is the question that comes up in almost every first conversation, usually near the end, usually phrased apologetically. What if you get hit by a bus? What if you sell up? What if, in three years, we ring the number and nobody answers?

It is a fair question and it deserves a straight answer rather than reassurance. Suppliers do close, get bought, retire, or simply stop replying. The useful thing is that whether that leaves you stranded is decided almost entirely before it happens, by a handful of practical arrangements that cost very little to get right at the start.

The software does not stop

First, the thing that panics people is the thing that will not happen. Software does not expire when its author does. If your system is running on a server this morning, it will be running tomorrow morning, and the morning after that, whether or not anyone is answering the phone.

What you lose is not the system. It is the ability to change it, and the ability to fix it when something outside it changes: a Windows update, a new version of the accounts package, an expiring certificate, a payment provider retiring an old API. Those things arrive on their own schedule. A system nobody can touch works perfectly until the first time the world moves underneath it, and then it does not.

That is the real risk, and it is a slow one. Which is good news, because it means you have time to prepare for it, and preparation is cheap.

The five things that decide whether you are stranded

Being able to hand your system to another developer comes down to five things. None of them is technical work you have to do; all of them are things you either hold or you do not.

The source code, in your own repository. Not a zip file emailed at the end of the project, and not a copy that lives only on the supplier's machine or in the supplier's account. A repository you own, that you can add a new developer to on a Tuesday morning without anybody's permission. If the only copy of the code is somewhere you cannot log in to, everything else on this list is academic.

Written ownership. Paying for code does not, by default, make you the owner of it under UK law, which surprises most people. That is worth understanding properly, and we go through it in who owns the code when you commission bespoke software. The short version: get the assignment in writing at the start, because afterwards you are negotiating with someone who has no reason to negotiate.

The credentials. The hosting account, the domain registrar, the database, the SSL certificates, the email sending service, any paid third-party APIs. In your business's name, on your business's card, with your business's email address on the account. This is the single most common failure. Code you own but cannot deploy is not much use, and domains registered under a departed developer's personal account are genuinely difficult to recover.

Boring, standard technology. A system built with widely used tools can be picked up by any competent developer. A system built on something obscure, or on a framework the original author invented, narrows the pool of people who will take it on and raises the price of every one of them. You do not need to understand the technology choices, but you are entitled to ask one question: how many developers in the UK could work on this?

Documentation. Enough for a new developer to get the system running locally, understand the deployment, and find their way around. It is the piece most often missing because it is the piece nobody sees until it matters. It should be part of the build rather than an extra, which is one of the reasons a realistic timeline includes handover, something we cover in how long bespoke software takes.

The test you can run this week

If you already have bespoke software, here is how to find out where you stand, and it does not require any technical knowledge.

Ask your supplier, in an email, for three things: a copy of the current source code, a list of every service the system depends on and whose name the account is in, and a short written note on how to deploy it. Say plainly that this is for continuity rather than because you are unhappy.

The response tells you almost everything. A supplier confident in their work will send it, or better, point out that you already have access to all of it. A supplier who stalls, asks why, or explains that it is not usually provided has answered a different and more important question.

Then do the other half yourself. Log into your domain registrar and your hosting and check whose name and email are on the accounts. Confirm you can get in without asking anyone. If you cannot, that is the first thing to fix, and it is usually an afternoon's work rather than a project.

What about escrow?

Source code escrow (lodging a copy with a neutral third party, released to you if the supplier fails) is the formal answer to this problem, and for large licensing arrangements it earns its keep.

For most bespoke work at SME scale it is ceremony. If you already own the code and already hold it in your own repository, there is nothing to put in escrow, because you have the thing escrow exists to deliver. It is worth considering when the supplier retains ownership, which is a situation better avoided in the first place.

If it has already happened

A good share of the work we are asked to do starts here: a system that runs the business, built by somebody who is no longer around, that nobody dares change. Sometimes it is a Microsoft Access database, sometimes a web application, sometimes a Visual Basic tool from twenty years ago.

It is recoverable more often than people expect. The order tends to be:

Secure what exists. Take a full backup of the system and its data, and put it somewhere that is not the same server. Before anything else.
Establish what you actually control. Domain, hosting, database, third-party accounts. Regain access where you can, and document where you cannot.
Find the source. It is often on the old server, in an old repository, or on a machine in a cupboard. If it genuinely does not exist, that changes the options but does not close them.
Get someone to read it. A few days of a developer's time will tell you whether the system can be maintained, needs partial replacement, or should be rebuilt. That assessment is worth paying for before you decide anything.

The part that surprises people is that an orphaned system is a considerable asset in a rebuild. Years of real business rules are encoded in it, and reading what is already there is a far better specification than a blank page. That is most of what legacy system replacement work involves, and the same pattern shows up in our guide to Microsoft Access end of life. If you are weighing up cost, the bands are published on the bespoke software cost page.

The honest summary

You cannot make a supplier permanent. You can make yourself independent of one, and the difference between a business that loses a developer and shrugs and a business that loses a developer and has a crisis is not luck. It is five arrangements, all of which are free to ask for before the work starts and expensive to obtain afterwards.

Ask any developer you are considering how you would leave them. If the answer is clear, unbothered and specific, you have learned something good. If it is vague, you have learned something more useful.

If you would like a straight opinion on where your current system stands, or what handover would look like on a project you are considering, get in touch.

What happens to your bespoke software if the developer disappears?