I am going to argue against my own commercial interest for a few hundred words.
The most common software problem I get called about is not a broken system. It is a working system that nobody can change. The firm that built it has gone quiet, or wants several times what they charged last year, or still exists and still answers the phone and genuinely cannot help, because the person who understood it left.
Three versions of the same morning
Suppliers go quiet. Small firms close, get bought, or simply decide your account is not worth the effort at the price you agreed three years ago. Nobody sends an announcement. Replies get slower until they stop.
Prices move. The first year was cheap because winning the account was the point. The renewal was always where the money lived, and by then moving is expensive, which both sides can see clearly.
People leave. This is the most common one and the least discussed. A great many systems in this region are held up by one developer who never wrote anything down and never had to. When they resign, your supplier is still trading, still polite, and still unable to do very much for you.
Hold these in your own name
Most of the protection is administrative rather than technical, and it costs nothing at all if you do it at the start of a project instead of during an argument.
- The cloud account, the domain name and the hosting are registered to your company with one of your own people as the contact. You add the supplier as a user. If they hold the account, they hold you.
- The code lives in a repository your company owns and pays for. You give the supplier access to it, not the other way round.
- You can export your own data yourself, in a format something else can read, without asking permission. Try it once during the project rather than finding out during a dispute.
- Any outside service the system depends on is on an account billed to you.
- There is a written description of what the system does and how it hangs together, kept current, aimed at somebody who was not involved in building it.
None of that is an unusual thing to ask for. A supplier who resists it is telling you something worth hearing.
The one-person problem, on both sides
Ask a supplier how many of their people could pick your system up tomorrow morning. If the honest answer is one, that risk sits with you, not with them. It is fair to ask what happens if that person is unavailable for a month, and to notice how quickly the answer arrives.
Then ask the same question inside your own organisation. If one person in your company is the only one who understands how an order moves from enquiry to invoice, you have the identical problem in a different building, and no contract protects you from it.
We are a small firm and the same principal leads every engagement, so I have to answer this one honestly rather than cleverly. What we do about it is that everything runs in your environment rather than ours, the documentation is written for whoever inherits it, and your people are in the build rather than receiving it at the end. That does not make us replaceable overnight. It does mean a competent firm you have never met could take it on.
Two clauses worth adding
First, write down what happens on the last day of the relationship, whatever ends it: what gets handed over, in what format, within how many days, and that none of it is conditional on there being no dispute over the final invoice. Handover held hostage to a payment argument is common and it is avoidable with one paragraph.
Second, state that the supplier has no right to cut off your access to anything as a way of settling a commercial disagreement. It sounds aggressive. It is not. Any supplier who never intended to do it will sign it without comment.
The test
Could a firm you have never met take this system over within a month, using only what you hold today, if we vanished tonight?
If the answer is no, work out which of the items above you are missing. The best time to fix it is before signing. The second best is at the next renewal, while you still have something to negotiate with. The worst time is the morning the emails stop being answered, which is when most people first think about it.
If you already have a system nobody can change and you are trying to work out what you actually own, that is a short and unusually useful piece of work. It is also work I am happy to do on something we did not build.
Working through this on a live programme?
A 45-minute call with the engineer who would run the work. We will tell you whether AI is the answer, including when it is not.