Custom software: build vs buy, done right / Own it long term
How to avoid vendor lock-in
The point of building custom software is control. You lose that control if only one vendor understands your code, or if your data is stored in a format only one tool can read. Owning software means keeping the freedom to change who maintains it and where it runs. Here is how to protect that.
Published July 27, 2026. Editorial.
Key takeaways
- Lock-in shows up when only one vendor understands your code or only one tool can read your data.
- Owning software means owning the ability to change who works on it, not just the code itself.
- Insist that your team owns the code, the accounts, and the knowledge from day one.
- Boring, standard technology and shared knowledge are the best protections against lock-in.
Companies build custom software to gain control over the part of their product that matters most. It is an unpleasant surprise, years later, to find that control quietly handed to someone else: a vendor who is the only one who understands the code, a platform you cannot move your data out of, a single engineer whose departure would stop all work on the system. Vendor lock-in is the slow loss of the freedom you built custom software to gain. This page is about keeping it.
What lock-in actually looks like
Lock-in has a few common forms. The first is code only one team understands, so you cannot change who maintains it without starting over. The second is data stored in a format only one tool can read, so leaving that tool means an expensive migration or losing your history. The third is depending so heavily on one platform's unique features that moving away from it would mean rebuilding large parts of your product.
None of these are visible at the start. They form slowly, through choices that felt convenient at the time. That is what makes lock-in dangerous: by the time it causes problems, undoing it is costly, which is exactly the power the vendor has over you.
Own the code, the accounts, and the knowledge
The first protection is ownership, and it is a thing you set up at the start, not fix later. Your company should own the code outright, in repositories you control. Your company should own the accounts the software runs on, so a vendor leaving does not take your infrastructure with them. And the knowledge of how the system works should stay with you, in documentation and known by more than one person.
This is one of the clearest differences between a real partner and a vendor who benefits from keeping you dependent. A good partner writes clear code, documents it, and makes sure your people understand it, because a good partner is confident enough to make itself replaceable. A vendor who keeps knowledge to itself is protecting its own position at your expense. The software development partner vs vendor piece explains that difference clearly, and the choosing a software development partner guide helps you find the first kind.
Boring technology reduces lock-in
The technology choice matters here too. Standard, widely-used tools are easy to leave, because many teams know them and your data is stored in common formats. Niche or proprietary tools are hard to leave, because few people know them and your data may only make sense inside them. This is another reason the boring, proven stack is usually the best choice, which we cover in how to choose a technology stack.
When you must use a proprietary service, and sometimes you should, keep the parts of your product that depend on it small and clearly separated. That way, if you ever need to move, you replace one separate piece rather than separating it from everything. The goal is not to avoid every vendor. It is to keep any single vendor from becoming impossible to leave.
Keep the knowledge shared
The most personal form of lock-in is a single person who is the only one who understands the system. That is a risk whether they are an outside vendor or your own employee. The day they leave, you lose the ability to change the software. This connects to maintaining custom software, because a system only one person can maintain is a system you do not truly own.
The protection is simple and it takes discipline: write things down, review each other's work, and make sure more than one person can work on every important part. Shared knowledge is slower in the moment and it is what keeps the software yours. Insist on it even when the team says it slows them down, because the alternative is far more expensive.
The freedom is the whole point
Avoiding lock-in is not about distrust. It is about keeping the control that made building worth it. Own your code, own your accounts, spread the knowledge, choose technology that is easy to move away from, and keep any single dependency small enough to replace. Do that and you keep the freedom to change who works on your software, which is the real meaning of owning it. This connects to the whole ownership question in the main guide. If you want a partner that builds to hand you control rather than keep it, that is how we work, and you can start there.
Common questions
What is vendor lock-in in software?
It is the slow loss of your freedom to change who works on your software or where it runs. It shows up as code only one vendor understands, data stored in a format only one tool can read, or heavy dependence on one platform's unique features.
How do I avoid vendor lock-in when building custom software?
Own the code, the accounts, and the knowledge from day one. Choose standard, widely-used technology that is easy to leave, keep any proprietary dependency small and separated, and make sure more than one person understands every important part of the system.
Does a good software partner create lock-in?
No, the opposite. A good partner writes clear code, documents it, and makes sure your people understand it, because it is confident enough to make itself replaceable. A vendor who keeps knowledge to itself is protecting its own position at your expense.
How do I know if my company is already locked into a vendor?
Check whether your company owns the code outright in repositories you control, owns the accounts the software runs on, and whether more than one person understands how the system works. If any of those depend entirely on one outside vendor or one employee, that dependency is a form of lock-in already in place.
Is vendor lock-in only a risk with bought software?
No. Lock-in can happen with custom software too, if only the team that built it understands the code or if your data is stored in a format only their tools can read. Owning custom software means owning the ability to change who maintains it, not just owning the code itself.
How much does it cost to fix vendor lock-in after it happens?
It varies by how large the dependency is, but undoing lock-in is always more expensive than preventing it, since it usually requires a costly migration or rebuilding parts of the product that depended on one vendor's unique features. That cost is exactly the power the vendor holds over you once lock-in has set in.
What is the safest way to use a proprietary tool without risking lock-in?
Keep the parts of your product that depend on the proprietary tool small and clearly separated from the rest of the system. That way, if you ever need to move off it, you replace one separate piece instead of separating the dependency from everything else the software does.
Should a single trusted engineer be allowed to be the only person who understands a system?
No, even if that engineer is fully trusted today. The day they leave, you lose the ability to change the software. Spreading the knowledge through documentation and shared code review is slower in the moment but is what keeps the software actually yours over time.