Avoid Vendor Lock-In in Software Development: 10 Safeguards

To avoid vendor lock-in in software development, set things up so another developer could take over your system next month without rebuilding it. In practice that comes down to ten safeguards: accounts in your company's name, a mainstream tech stack, documentation that works, and data you can export yourself.

I'm a freelance developer based in Denmark, so I'm not a neutral party here. My clients own their code from day one, precisely so they can leave me without drama, and you should expect the same from any freelancer or agency you hire.

The short answer

If you only do three, do 1, 3 and 6. They give the most protection for the fewest hours. Starting from scratch? My guide to hiring a developer covers the process from first brief to signed contract.

Ownership and access: the foundation

The first two safeguards aren't technical. They decide whether you can switch at all, however good the code is.

1. Every account is in your company's name

Your code repository, hosting, database, domain, payment provider, email service and AI APIs should all be created by your company and paid for with a company card. The developer is invited as a user with the permissions the job needs, and you can remove them without asking anyone. API keys (the credentials your app uses to talk to other services) belong in a password manager your company controls, such as 1Password or Bitwarden.

This sounds obvious, yet it's where lock-in typically starts. A developer creates an account to get going quickly, and two years later everything still runs on it. How to move repos and domains, and why a zip file of the code isn't the same as owning it, is covered in my article on who owns the code a freelance developer writes.

2. A contract with IP assignment and an exit clause

The contract should assign the intellectual property in the code to you, including the right to modify it and let other developers build on it. It should also describe how the relationship ends:

• a reasonable notice period, so you're never left without a developer overnight
• a duty to help with the handover, usually at the normal hourly or day rate
• a list of what gets handed over: code, documentation, credentials and data

An exit clause isn't a sign of distrust. It makes a switch boring instead of dramatic, and a professional developer has no reason to refuse one. The other clauses worth having are in my freelance developer contract checklist.

Technology: build on what many developers know

Technical lock-in is harder to spot, because it only costs you something on the day you try to leave. Three choices decide most of it.

3. Choose a mainstream stack

The more developers who work with the technology your system is built on, the easier it is to find a new one. A Laravel, Django, Ruby on Rails, .NET or React/Next.js app on PostgreSQL or MySQL can be picked up by a large pool of developers. A system built on an in-house framework or a niche language can be picked up by a handful.

My test is simple: can you name three other freelancers or agencies who work with exactly that stack? If not, ask your developer why they chose it. Be wary of a long tail of small, obscure packages too. If one stops being maintained, you're stuck on an old version or paying someone to replace it.

I work with Laravel and React/Next.js myself, and that's one of their advantages: they're common enough that a client doesn't depend on me to find someone who can carry on.

4. Keep your business logic in your own code

Business logic is the set of rules that makes your system yours: how prices are calculated, who can see what, what happens when an order is canceled. If those rules live in your own codebase, they move with you. If they're scattered across a no-code platform, one cloud provider's proprietary functions or the settings of a paid tool, they stay behind.

That doesn't mean avoiding third-party services. You'll almost always buy payments, email, SMS and AI rather than build them. A good developer wraps each one behind a thin layer in the code, so the rest of the system doesn't know which provider sits behind it. Changing email provider or AI model then means editing one place, not a hundred.

Laravel shows the principle well. Its filesystem layer uses the same code for local files and S3-compatible storage, and the docs list alternatives to Amazon S3 such as Cloudflare R2 and Hetzner, a German provider. Moving between S3-compatible providers is typically a matter of new credentials and a new endpoint in the config. You still have to copy the files, but you don't have to rewrite the code.

5. Hosting you can move

Your app should run on a standard Linux server or in a standard container (Docker, for example) with more than one provider. Configuration such as database credentials, API keys and URLs belongs in environment variables, not in the code. That's one of the principles of The Twelve-Factor App, which offers a useful test: could the codebase be made public tomorrow without leaking a single password?

Serverless platforms and managed services from the big cloud providers can be the right call. But every provider-specific service your app depends on is something to rewrite when you move. Choose them deliberately and write the choice down (see safeguard 8). If you're in the EU, picking a provider with EU data centers from the start also spares you a forced move later if data protection questions come up.

Knowledge: get it out of one person's head

Even with the right accounts and a mainstream stack, you can still be locked in if everything that isn't in the code lives in one person's head.

6. A README that actually works

The README is the file at the top of the repository that explains the project. At minimum it should cover how to set the project up on a new machine, how it's deployed, which external services it uses and where the credentials live.

My rule of thumb: an experienced developer should have the project running on their own machine within their first working day, without calling anyone. The README is also the first thing to hand over when onboarding a freelance developer. For everything else worth writing down, see my software documentation checklist.

7. Automated tests and deployment

Automated tests are code that checks the system does what it should. For you, they're more than quality control: they're documentation that can't go out of date. A new developer can change something and see straight away whether anything else broke. Without tests, nobody dares touch the code, and you're effectively tied to whoever wrote it.

The same goes for deployment, meaning how new versions go live. It should run through an automated pipeline (CI/CD, a process that tests and releases the code) stored in your repository, for example with GitHub Actions. It should never depend on one developer's laptop and a set of commands only they remember.

8. A written decision log

Why that database? Why two payment providers? Which shortcuts were taken to hit the launch date? These answers are often what a new developer misses most, because they decide whether something odd in the code is a bug or a deliberate choice.

A short decision log in the repository fixes this. Each decision gets a few lines: what was decided, why, and what the alternative was. It takes minutes to write and saves hours during a handover. Note the known technical debt too, meaning the places where the code was deliberately done fast rather than thoroughly.

Keep the exit open while things are going well

The last two safeguards make sure you can actually get out, and they're best done while everything is still running smoothly.

9. Data you can export yourself

Your data is often worth more than your code. Make sure database backups land in an account you own, and that you can download one without asking anyone. If the system relies on external platforms, check that you can export your data in a standard format such as CSV or JSON, and that the export is complete, including history and files.

Try it once. Better to find out the export is missing something now than on the day you need it.

10. Rehearse the handover

The only real proof that you're not locked in is that another developer has actually worked in the system. Once a year, or at major milestones, bring in an independent developer for a code review or a small, well-defined task. Give them access, let them follow the README, and see where they get stuck.

It costs a few hours, which is far cheaper than discovering the gaps when your regular developer suddenly isn't available. A good developer won't be offended. These are the same questions a buyer or investor will ask in due diligence if you ever sell the company.

Are you already locked in? A five-question test

Answer these honestly:

1. Can you log in to your repository, hosting and domain registrar with your own user today?
2. Does your contract say you own the code and can let others build on it?
3. Can you name three other developers or agencies who work with your stack?
4. Is there a setup guide that another developer has actually tried to follow?
5. Can you download a complete backup of your data without asking anyone?

One or two "no" answers don't mean you're in trouble, but you have work to do. With three or more, fix it while your relationship with your current developer is still good. Getting access and documentation from a developer who's happy with the collaboration is much easier than from one you've just let go. If things have already broken down, follow my guide on how to switch developers mid-project.

When some lock-in is the right call

All software ties you to something. The goal is to know what switching would cost and to have accepted that cost on purpose.

• For a webshop, a booking system or accounting, Shopify or an established SaaS product usually costs less than a custom build, even though you're locked into the platform. Just make sure you own the domain and can export your data.
• A managed database or a transactional email service adds a small dependency and saves you a lot of operations work. That's usually a good trade.
• An internal tool with five users doesn't need the documentation and test coverage of your core product. Weigh the effort against what a rebuild would cost.

The same applies if you're thinking of hiring me. If what you need exists off the shelf, buying it is usually smarter than paying me or anyone else to build it. And if your system is built in Java or .NET, a developer who works in that stack is a better choice than me to take it over.

Next steps

Run this checklist against your current system, or bring it to your first calls with a new developer.

Start with the items you can't tick, and fix accounts and the contract first. If you have an existing system that needs reviewing, cleaning up or preparing for a new developer, here's how I handle maintenance and further development of existing web apps. You own the code from day one, so you can move on from me whenever you want.

Frequently asked questions

What is software escrow, and do I need it?+

Software escrow means an independent third party holds a copy of the source code and releases it to you if the vendor goes bankrupt or stops supporting the product. It's relevant when you license software and don't own the code yourself. If your code already lives in your own repository, you rarely need it, because you have the code all along. An escrow copy is also only useful if it's kept current and can actually be built.

Does avoiding lock-in make a project more expensive?+

A little, but far less than fixing it later. Accounts in your name and a mainstream framework cost almost nothing extra. A proper README, tests and a thin layer around third-party services add some hours along the way. Retrofitting documentation and tests onto a live system, or rebuilding parts tied to one provider in the middle of a switch, typically costs much more.

Is it a red flag if my developer hosts the app for me?+

Not necessarily. Many freelancers and agencies offer hosting and maintenance as part of the deal, and it can be convenient. The problem starts when you have no admin access, can't download a backup, or can't move the app without the developer's help. Ask for admin access, backups you can fetch yourself and a written agreement on how the app is handed over if you part ways.

What if my app was built with a no-code tool or an AI app builder?+

You can reduce the lock-in, but rarely remove it. With no-code platforms, both your data and your business logic live with the vendor, so moving usually means rebuilding. Some AI app builders can export the generated code to your own repository, which helps a lot. Check what your tool can export before you build anything business-critical on it, and expect the code to need a review before a developer can extend it.

Does it matter if my developer is based in another country?+

Less than you might think, as long as the safeguards are in place. With accounts in your name, code in your repository and a working README, a developer abroad is no harder to replace than a local one. What changes is enforcement: chasing a contract across borders is slow and costly, so the practical safeguards matter more than the legal ones. Agree on governing law and the contract language up front, and have a lawyer check the cross-border terms.