Most business owners assume that if they paid for a piece of software, they own it. It is a reasonable assumption. It is also, quite often, only partly true.
Software ownership is not one thing. It is a bundle of separate things: the source code, the rights to that code, the accounts it runs in, the domains that point to it, the services it relies on and the knowledge needed to keep it going. You can own some of these and not others, and the gaps tend to stay invisible until something goes wrong.
Why this matters more than it seems
Day to day, ownership feels academic. Your supplier is helpful, the system works, invoices get paid. The question becomes urgent at specific moments: when a supplier closes or is sold, when a relationship sours, when a developer leaves, when you want a second opinion, or when an investor, buyer or auditor asks you to prove what you hold.
At those moments, what matters is not what you assumed. It is what you can actually demonstrate, and what you can actually access without asking anyone's permission.
The five things to check
1. Source code ownership
There are two parts to this: having the code, and having the rights to it.
Having it means the code sits in a repository your business controls, with full history, and that more than one of your people can get in.
Having the rights is a legal question. In the UK, copyright in code written by an employee in the course of their job usually belongs to the employer. Code written by a contractor or an agency usually stays with them unless it has been assigned to you in writing. Many contracts handle this well; some are silent or ambiguous. Read yours, and if it is unclear, take legal advice on the specifics.
2. Hosting and cloud accounts
Your system might run in an AWS, Azure or Google Cloud account, or with a hosting company. Whose name is on the account? Whose card pays for it? If the supplier owns the account and simply recharges you, they control your system in a very practical sense.
3. Domains and DNS
Check who is listed as registrant for each domain your system uses. It should be your company. If the domain is held by a supplier or an individual, ask for it to be transferred.
4. Third-party services and licences
Bespoke systems often depend on paid components and services: email delivery, SMS, payments, mapping, reporting tools, commercial libraries. Some of these may be licensed to your supplier rather than to you, which means they could stop working if that relationship ends.
5. Documentation and knowledge
Even with full legal ownership and every login, you can still be locked in if only one supplier understands how the system works. Documentation, deployment instructions and a record of known issues are part of what you own in practice.
Ownership checklist: what to confirm this month
The code repository is in a company-owned account, with at least two admins from your business.
Your contracts clearly assign intellectual property in bespoke code to your company, or you have taken advice on how to fix that.
Hosting and cloud accounts are in your company's name and billed to you, with your people holding admin access.
Domains are registered to your company, and you know who can change DNS.
You have a list of third-party services and licences, with a note of who holds each one.
Backups are stored somewhere you control, and someone has tested a restore.
Up-to-date documentation exists covering how to deploy, configure and recover the system.
Your support contract says what you receive if you leave: code, data, credentials and documentation.
Lock-in is usually quiet, not malicious
Software supplier lock-in is rarely the result of bad intent. More often it builds up through convenience: the supplier set up the hosting because it was quicker, registered the domain because you asked them to sort it, and never got round to writing things down because nobody asked.
That is why a polite conversation usually fixes most of it. Ask your supplier to help you move accounts into your name and to confirm the IP position in writing. A good supplier will not mind. If the request meets resistance, that is useful information too.
What good looks like
The healthy arrangement is simple. Your business owns the code, the accounts and the documentation. Your supplier works inside your accounts, with access you grant and can revoke. If you ever decide to move on, there is a clear, agreed process for handing everything over, and the next team can pick it up without detective work.
You should be staying with a supplier because they do good work, not because leaving would be too hard.
How Scaffold can help
Scaffold Care is built on the principle that you leave with everything: your code, cloud accounts and documentation stay yours, and we provide an exit pack if you ever move on. Our fixed-price Health Check reviews your code, hosting, security and risks, including where ownership gaps sit, and tells you what level of care the system needs. You keep the report whether or not you go ahead with us.
Book a Health Check and find out exactly what you own.
