Vendor lock-in is the situation where switching away from your software provider is so difficult or expensive that you are trapped. With SaaS, lock-in is built into the business model: proprietary data formats, limited exports, and deep platform integration. With bespoke software, lock-in is preventable. Four contract terms ensure you are never trapped: you own the source code, the software uses standard technologies, you receive full technical documentation, and you have admin access to all accounts. With these in place, any competent developer can maintain your software, not just the original builder.
This guide explains how to prevent vendor lock-in when commissioning custom software. These are contract terms and practical steps, not aspirations. See our guide on choosing a development partner for the broader selection process.
What Causes Vendor Lock-In with Custom Software?
Custom software can create lock-in if the right protections are not in place. The four causes:
- You do not own the source code: The developer retains the intellectual property and gives you only a licence to use the software. You cannot modify, extend, or maintain it without their permission. If they raise prices or stop supporting it, you have no recourse.
- The software uses proprietary or niche technologies: The software is built with frameworks or tools that only the original developer understands. No other developer can maintain it without extensive retraining. This is sometimes deliberate: it ensures you keep coming back.
- No technical documentation: Without documentation, a new developer would need weeks or months to understand the system before they could make changes. The cost and time of this learning curve makes switching impractical.
- The developer controls all access: The code repository, hosting account, domain registration, and third-party service accounts are all in the developer name. To switch, you would need to recreate everything from scratch.
Each of these is preventable with the right contract terms and practices. None of them are accidental; they are choices made during the project setup.
How Do You Ensure You Own the Source Code?
Source code ownership is the most critical protection against vendor lock-in. Without it, you do not truly own your software, regardless of what you paid for it.
What to ensure in the contract:
- IP assignment: The contract must state that intellectual property, including all source code, is assigned to you (or your company). This is different from a licence, which grants you the right to use but not own.
- Code delivery: The source code must be delivered to a code repository (like GitHub, GitLab, or Bitbucket) that you control. You should have admin access. The developer should not be the only one with access.
- Third-party licences: The contract should clarify which parts of the software are custom-built (owned by you) and which are third-party libraries (licensed under their own terms). Most software uses open-source libraries; you need to ensure the licences allow your use.
- No proprietary frameworks: The contract should state that the software will not use proprietary frameworks owned by the developer. All code should be in standard, widely-used languages and frameworks.
Without explicit IP assignment in the contract, the default legal position in the UK is that the developer retains ownership of the code they write, even though you paid for it. This is a common and expensive misunderstanding.
What Technologies Should Your Software Use?
The technology choices determine whether another developer can maintain your software. Mainstream technologies with large developer communities are maintainable by anyone. Niche or proprietary technologies create lock-in.
Recommended standard technologies:
- Frontend: React, Vue, or Astro (TypeScript). All have massive developer communities and are widely supported.
- Backend: Node.js (TypeScript) or Python. Both are mainstream with extensive ecosystems.
- Database: PostgreSQL or MySQL. Both are open source, widely understood, and have decades of community support.
- Hosting: AWS, Azure, or Google Cloud. Standard cloud platforms with extensive documentation and alternatives.
- Mobile: React Native or native Swift (iOS) and Kotlin (Android). All are widely supported.
Technologies that create lock-in:
- Proprietary frameworks developed by the development company
- Niche languages with small developer communities
- Custom-built CMS or admin panels (instead of standard solutions)
- Hosting on the developer own infrastructure (instead of standard cloud platforms)
If your development partner recommends a technology you have not heard of, ask how many developers in the UK could maintain it. If the answer is "only us", that is lock-in.
What Documentation Should You Receive?
Documentation is what makes the software maintainable by someone other than the original developer. Without it, switching developers requires a lengthy and expensive knowledge transfer. With it, a competent developer can understand the system in days, not months.
Documentation you should receive:
- Technical architecture document: How the system is structured, what technologies are used, and how components interact.
- Database schema documentation: Every table, field, relationship, and index, with explanations of what each stores.
- API documentation: If the software has an API, full documentation of every endpoint, request format, and response format. See our guide on custom API development.
- Deployment instructions: Step-by-step instructions for deploying the software to a new environment. This ensures you are not dependent on the original developer for deployment.
- Environment setup guide: How to set up a development environment, including all dependencies and configuration.
- User documentation: Guides for users on how to use the software. Not the same as technical documentation.
Documentation should be a deliverable in the contract, not a favour. It should be produced during development, not bolted on at the end.
How Do You Ensure You Control Access?
Access control is about ensuring you can operate the software independently of the original developer. If the developer holds all the keys, you are dependent even if you own the code.
Access you should control:
- Code repository: You should have admin access to the Git repository. The developer should not be the sole admin.
- Hosting account: The cloud hosting account (AWS, Azure, Google Cloud) should be in your name, not the developer. You should have admin access.
- Domain registration: Your domain should be registered in your name. The developer should not control your domain.
- Third-party services: Accounts for email sending, payment processing, monitoring, and any other third-party services should be in your name.
- Credentials: You should have all passwords, API keys, and credentials. Store them securely. If the developer holds them exclusively, you are dependent.
If any of these are controlled solely by the developer, switching to a new partner requires recreating that access from scratch, which may mean downtime and data loss.
What Contract Terms Protect You?
The specific contract terms that prevent vendor lock-in:
- IP assignment clause: "All intellectual property, including source code, created under this agreement is assigned to [Your Company]."
- Standard technology clause: "The software will be built using standard, widely-supported technologies. No proprietary frameworks owned by the developer will be used."
- Documentation delivery clause: "Full technical documentation, including architecture, database schema, API documentation, and deployment instructions, will be delivered as part of the project."
- Access provision: "All code repositories, hosting accounts, domain registrations, and third-party service accounts will be set up in the client name with client admin access."
- Code handover clause: "Upon project completion or termination, all source code, documentation, credentials, and access will be transferred to the client within 7 days."
- Source code escrow (optional): For additional protection, source code can be held in escrow, releasing to you if the developer becomes unable to maintain it.
These terms are standard for reputable development partners. A partner who resists them is a red flag. See our guide on custom software risks for the full risk framework.
How Do You Verify You Are Not Locked In?
After launch, verify your independence with a simple test: could another developer take over maintenance tomorrow?
- Can you access the source code repository? Yes or no.
- Can you deploy the software without the original developer? Yes or no.
- Do you have documentation sufficient for a new developer to understand the system? Yes or no.
- Do you control the hosting, domain, and third-party accounts? Yes or no.
- Does the software use standard technologies that any developer would recognise? Yes or no.
If any answer is "no", address it immediately, while the original developer is still engaged. After the relationship ends, fixing these issues is much harder.
Ready to start a project with lock-in protection built in? Book a free discovery call, or see our services for what we build.