Here's a question most business owners never ask until it's too late: if you fell out with your software supplier tomorrow, could you walk away with everything you need? The code, the data, the keys to the hosting? For a lot of companies the honest answer is no — and that's exactly how vendor lock-in works.
Lock-in isn't always malicious. Sometimes it's just sloppiness. But the effect is the same: you keep paying because leaving is harder than staying. This article breaks down where lock-in actually comes from, how to spot it before you sign, and what to do if you're already stuck.
What vendor lock-in really means
Lock-in is any situation where the cost of switching suppliers is high enough that you stay put even when you'd rather not. It's not the same as a good relationship — a good supplier you keep by choice. Lock-in is when the choice has quietly been taken away from you.
It shows up in four places, and most stuck companies have a problem in more than one:
- The code. You paid for it, but you don't have it — or you have it and nobody can run it.
- The data. Your customer records and history live in a system you can't export cleanly.
- The hosting and infrastructure. The servers, domains and accounts are in your supplier's name, not yours.
- The knowledge. Nobody but the original builder understands how the thing actually works.
1. Who owns the code?
This is the one people get wrong most often. Paying for custom software does not automatically mean you own it. Without a clear clause in the contract, the developer can keep the copyright and grant you only a licence to use it — which they can revoke or reprice.
What you want in writing: full transfer of intellectual property to your company on final payment, and the source code delivered in a repository you control (your own GitHub or GitLab organisation, not theirs). If a supplier hesitates on either point, that hesitation is your answer.
And "having the code" isn't enough if no other developer can make sense of it. Ask whether it comes with a README, setup instructions and reasonable documentation. Undocumented code you technically own is still a form of lock-in — you can't hand it to anyone else without paying for weeks of reverse-engineering first.
2. Can you get your data out?
Your data is yours, but only if you can actually extract it. Plenty of systems make getting data in effortless and getting it out a nightmare. Before you commit, ask one concrete question: "Can I export everything — customers, transactions, files — to a standard format like CSV or JSON, on demand, myself?"
If the only way to get your own data is to request a paid export from the supplier, you don't control your data. You're renting access to it.
3. Whose name is on the hosting?
I've seen companies discover, mid-dispute, that their domain name, cloud account and SSL certificates were all registered under their developer's personal email. At that point you're not negotiating from strength — you're negotiating to get back things that should have been yours all along.
Every account that runs your business should be in your company's name, with you as the owner and the supplier added as a collaborator. That includes the domain, the hosting (AWS, Azure, Vercel, whatever it is), the database, and any third-party services with API keys. Suppliers come and go. The accounts should stay with you.
4. The single-developer knowledge risk
There's a legitimate version of the "what if you get hit by a bus?" worry, and it applies whether you hire a freelancer, a small studio or a big agency: what happens when the person who built it is no longer available?
The protection here isn't the size of the supplier — big agencies lose the original team to staff churn just as easily. The protection is standard, boring technology and good documentation. Software built on widely-used frameworks, with its code in your repository and a clear handover document, can be picked up by any competent developer. Software built on someone's clever proprietary setup cannot. When you evaluate a partner, ask what stack they use and why — "because any developer can maintain it" is a better answer than "because it's our own framework."
The questions to ask before you sign
You don't need to be technical to protect yourself. Put these in front of any supplier and watch how they react:
- Do we own the intellectual property to the code outright once it's paid for? Is that in the contract?
- Will the source code live in a repository owned by our company?
- Are the hosting, domain and all third-party accounts registered in our name?
- Can we export all our data ourselves, anytime, in a standard format?
- What does a handover to another developer look like — and what does it cost?
A good partner answers all five without flinching, because they've got nothing to protect. The whole point of doing the work well is that you could leave — you just won't want to.
Already locked in? Start here
If you read this with a sinking feeling, don't panic-rebuild. Start by reclaiming the cheap wins: get the domain and hosting accounts transferred into your name, and request a full data export today so you at least have a copy. Then ask for the source code and an honest assessment of how portable it is. You may find you're freer than you thought — or you'll know exactly what a rebuild would involve, which is useful either way. It's worth weighing against the cost of custom software done properly from the start.
Avoiding lock-in costs almost nothing if you sort it out upfront. It's only expensive once you're already trapped. The same logic runs through how I think about maintenance after launch and choosing between off-the-shelf and custom: keep your options open, own what matters, and never let convenience today become a cage tomorrow.
Want a second opinion on a contract or an existing system before you commit? Send me the details — I'll tell you straight where the risk is.