Vendor Lock-In in Custom Software: What You Should Own, and How to Keep It

Choosing a software partner is a bigger decision than choosing what to build, because the partner decides how easily you can ever leave. Vendor lock-in rarely shows up in the proposal. It shows up two years later, when you want to bring the work in-house, switch partners or simply add a second team, and discover that the code is yours on paper but the system is not yours in practice.

This insight is about that gap: what "we own it" actually has to mean in custom software and AI projects, where lock-in usually hides, and how to build ownership into the engagement from the first week rather than negotiating it at the end.

What ownership actually requires

Owning a custom system is not one right. It is six layers, and lock-in can live in any one of them.

1. Source code and history. The full repository, in an organisation you control, with its commit history and branches. A zip file at the end of the project is a copy, not ownership.
2. Infrastructure and accounts. Cloud accounts, domains, app store listings, certificates, CI/CD pipelines and third-party subscriptions registered to your company, with your people as administrators.
3. Data and schemas. Your data in a database you can access directly, plus the schema, migrations and any data model documentation needed to understand it without the vendor.
4. Documentation and decisions. Architecture diagrams, an up-to-date README, API documentation and a record of why key decisions were made. The "why" is what your next team will need most.
5. Operational knowledge. Runbooks for deployment, monitoring, incident response and routine maintenance. This is the knowledge that usually lives only in the heads of the people who built it.
6. Dependencies and licences. A list of every proprietary component, licensed library, paid API and AI model provider the system relies on, with who holds each contract.

A partner who hands over the first layer but keeps the other five has not given you ownership. They have given you the hardest part to use on its own.

Where lock-in hides

Code you own but cannot run

The contract says the source code is yours, and it is. But the build depends on scripts that only exist on the vendor's machines, environment variables nobody wrote down and a deployment process one engineer runs by hand. You own the code and still cannot ship a release without the vendor.

Accounts in the vendor's name

The production cloud account, the Apple developer account or the domain is registered to the vendor because it was faster at the start. Moving them later means downtime risk, app re-submissions and a negotiation you did not plan for.

Proprietary frameworks and internal tools

Some vendors build on their own in-house framework, low-code layer or admin platform. It speeds up delivery, and it also means no other team can maintain the system without licensing that layer or rewriting around it.

Knowledge that was never written down

The most common form of lock-in is not technical. The system works, the code is clean, but the reasons behind the data model, the edge cases in the integrations and the workarounds for a legacy system live in a few people's heads. When those people leave the project, the knowledge leaves with them.

The AI layer

AI projects add a newer kind of dependency: prompts, evaluation sets, fine-tuning data, retrieval pipelines and agent configurations. If these sit in the vendor's tooling, or the system is hard-wired to a single model provider, switching partners or providers means rebuilding the part that took the longest to tune.

The easy answer, and why it is not enough

The easy answer is "put source code ownership in the contract." It is necessary, and on its own it does very little. Most lock-in we see does not come from a vendor refusing to hand over code. It comes from everything around the code that was never planned for handover.

The opposite easy answer is also wrong: trying to avoid depending on any partner at all. Every engagement creates some dependency, and that is healthy while the work is active. The real question is not "will we depend on them?" but "what would it cost us to leave, and is that cost going down over time or up?" A good engagement makes the exit cheaper every month. A risky one makes it more expensive.

Across 400+ projects, the handovers that went smoothly had one thing in common: the client could have run the system without us long before they actually needed to. Ownership was a habit of the project, not a document at the end.

A practical ownership plan, phase by phase

Ownership is easiest when it is built in from the start. This is the sequence we recommend, whatever partner you choose.

Before signing. Write the six layers into the contract: repository in your organisation, accounts in your name, documentation and runbooks as deliverables, a dependency and licence register, and a defined handover period. Ask the partner to show a real handover package from a past project, with client details removed.

Weeks 1-2: set up on your side. Create the code repository, cloud accounts, domains and store accounts under your company and give the partner access, not the other way around. Agree on where documentation lives and who keeps it current.

Every sprint: keep ownership current. Treat documentation, architecture decision records and runbook updates as part of the definition of done. Review the dependency register whenever a new library, paid API or model provider is added. If you have an in-house team, include at least one of your engineers in code reviews from the start.

Every quarter: test the exit. Ask someone outside the delivery team, ideally your own engineer, to build and deploy the system from the documentation alone. Whatever they get stuck on is your current lock-in, and fixing it while the project is active costs far less than fixing it during a handover.

Final phase: structured handover. Pair your team with the partner's engineers on real releases and real incidents, not just walkthroughs. Close the phase only when your team has shipped a release without help.

This is also how hybrid models work best: your team owns the product and the knowledge, and a partner accelerates the parts that need specialised capacity. The plan above keeps that balance from drifting.

What not to do

1. Do not accept "ownership at the end." If the repository, accounts and documentation only move to you at project close, you will discover the gaps when you have the least leverage to fix them.
2. Do not treat documentation as a final deliverable. Documentation written in the last two weeks describes what the team remembers, not what the system does. Make it a sprint-level habit.
3. Do not let convenience decide account ownership. "We'll set it up under our account for now" is the single most common way production infrastructure ends up in someone else's name.

Frequently asked questions

What is vendor lock-in in software development?

Vendor lock-in is the situation where moving away from a software partner becomes so costly or risky that you stay even when you would rather not. In custom software it usually comes from accounts, undocumented knowledge, proprietary tooling or deployment processes the vendor controls, rather than from the code itself.

Who owns the source code in custom software development?

Ownership depends on the contract, not on who wrote the code, so it should be stated explicitly before work begins. A strong contract assigns the source code, documentation and intellectual property to the client and requires the repository to sit in the client's own organisation from day one.

How do you avoid vendor lock-in with a software development company?

Put the code repository, cloud accounts and domains in your company's name from the start, make documentation and runbooks part of every sprint, and keep a register of all third-party dependencies. Then test the exit regularly by having someone outside the delivery team build and deploy the system from the documentation alone.

Is software escrow necessary for custom software?

Escrow is useful when you license software you do not own, because it protects you if the vendor stops operating. For custom software you own, escrow adds little if the repository already lives in your organisation; direct access to the code, accounts and documentation is stronger protection.

What should a software handover package include?

A complete handover package includes the full repository with history, infrastructure and account access, database schemas and migrations, architecture and API documentation, deployment and incident runbooks, and a list of every dependency and licence. It should end with your team shipping a release without help from the original partner.

Choosing a partner you could leave

The best sign of a partner worth staying with is that leaving them would be straightforward. For a deeper checklist of questions to ask before you sign, see our Enterprise Software Vendor Selection: 2026 CTO Checklist. Our own products, such as Portal CRM, Portal CMS and Fieldloop, run on clients' own servers for the same reason: control should stay with the business that depends on the system.

If you are planning a project and want ownership built in from the first week, talk to our team.