Blog

Vendor lock-in in software: what it is and how to avoid it

Benjamin · · 6 min read

Lock-in rarely feels like a problem at the start. The five kinds of software lock-in, how common tools compare, what the evidence shows, and practical ways to keep your options open while still connecting your tools.

Vendor lock-in is when leaving a software supplier would cost so much, in money, time or risk, that you effectively can't. It rarely feels like a problem at the start. The platform is easy, the agency is friendly, and the price is fair. It becomes one when prices rise, the product changes direction, the supplier is acquired or goes under, or you simply outgrow them, and you find that your business runs on something you don't control.

This guide explains the kinds of lock-in, what the evidence shows, how common tools compare, and practical ways to keep your options open, including how to connect tools without tying yourself to any one of them.

What the evidence shows

  • Some platforms can't be exported at all. Bubble, a popular no-code app builder, says in its own manual that you own your app's design and your users' data, while Bubble retains ownership of the underlying code, and that "Bubble apps can only be run on the Bubble platform; there's no way of exporting your application as code." Data can be exported as CSV files or through its API. (Bubble manual) That's an honest, clearly stated trade-off, but it means leaving requires a rebuild.
  • Suppliers can disappear. In May 2025, Builder.ai, a heavily funded AI app-building company, entered insolvency proceedings after creditors seized its funds, amid reports of overstated revenue. (Wikipedia) Whatever the cause, it's a reminder to plan for the day a supplier isn't there.
  • Lock-in shows up as waste. Zylo's 2026 SaaS Management Index, based on more than 40 million SaaS licences, found organisations leave an average of 36% of their licences unused. (Zylo) Freshworks' 2025 Cost of Complexity Report found respondents believed 20% of software budgets go on tools that are underused, poorly integrated or never fully implemented. (Freshworks) Part of that is software that's hard to leave.

The five kinds of lock-in

  1. Code lock-in. Your software only runs on the supplier's platform, or the supplier owns the code. Leaving means rebuilding.
  2. Data lock-in. You can't get your data out completely, or only in a form that loses the relationships between records, the history or the files.
  3. Contract lock-in. Long terms, auto-renewals, exit fees or price rises you can't refuse.
  4. Knowledge lock-in. Only the supplier understands how it works. Nothing is documented, so nobody else can maintain it.
  5. Integration lock-in. Your processes are wired into one product's automations and connectors, so replacing that product breaks everything around it.

Most businesses have some of each. The aim isn't zero lock-in, which is impossible. It's choosing it deliberately, and knowing your exit.

How common tools compare

SaaS products: CRMs, accounting, helpdesks

Lock-in: usually data and integration. Most let you export core records, but automations, history, attachments and custom setups are harder to move.

How to manage it: check export options before you commit, keep a regular export of your key data, and avoid building critical logic into one product's own automation tools when it really belongs to your business.

No-code platforms: Bubble, Glide, Softr, Airtable

Lock-in: often code. Your app's logic lives in the platform's format, and you can export the data but not the app.

How to manage it: use them for prototypes and tools you could rebuild, and understand the export position for anything critical. Bubble documents its position clearly. Ask the same question of every platform.

Low-code builders: Retool, Appsmith, Budibase

Lock-in: moderate. Your data stays in your own databases, but the screens and logic live in the builder's format. Open-source, self-hostable options like Appsmith and Budibase reduce the risk of the supplier disappearing.

How to manage it: keep business logic in your own database or code where you can, and prefer self-hostable options for critical tools.

Automation tools: Zapier, Make, n8n

Lock-in: integration. Dozens of automations encode how your business works, in one vendor's format.

How to manage it: document what each automation does, keep the important rules somewhere you control, and consider self-hostable options like n8n for core flows.

Agencies and developers

Lock-in: code, knowledge and contract. Some agencies retain the code, host it on their own accounts, or build on their own proprietary platform.

How to manage it: make sure the contract says you own the code once paid, the code lives in a repository you control, and documentation is part of the job.

Practical ways to stay free

  1. Own the code. For custom software, the contract should assign the code to you once it's paid for, and the code should be in a repository in your name throughout.
  2. Own the accounts. Hosting, domains, app store accounts and third-party services should be in your business's name, with your builder given access, not the other way round.
  3. Own the data, in a usable form. Test a full export before you depend on a tool. Make sure relationships, files and history come out too.
  4. Keep your business rules in one place you control. Pricing, approvals and matching rules scattered across five vendors' automation tools are the hardest lock-in to escape.
  5. Use standard building blocks. Mainstream languages, databases and hosting mean many developers can maintain the work.
  6. Insist on documentation. A short written explanation of how things fit together turns knowledge lock-in into a handover.
  7. Read the exit terms. Notice periods, auto-renewals, export fees and what happens to your data when you leave.
  8. Consider source code escrow for critical software from a supplier who keeps the code. An escrow agent holds a copy that's released to you if the supplier fails. See the software development contract checklist.

Connecting tools without locking yourself in

Connecting your tools is what makes a business run smoothly, but it's also where lock-in hides. The way to do it safely:

  • Let each product do its own job. Accounting stays in the accounting package and customers in the CRM. Any one of them can be replaced later.
  • Keep a shared record of your own: the IDs that link a customer, job or order across systems, in a database you own.
  • Put the connections and rules in your own code, talking to each product through its API, rather than inside one vendor's automation tool.
  • Then swapping a product is a contained job. Replace the CRM, rewrite one connection, and the rest of the business carries on.

That's the difference between a stack of rented parts and a system you own.

How we avoid lock-in at Lephlo

"You own the code" is one of our core commitments: once the project is paid for, the code and everything in it belong to you, with no licence fees and no lock-in. We build internal tools, customer portals and integrations on standard technology that other developers can maintain, and we connect the tools you already use through their APIs, with your rules in code you own.

It starts with a free consultation. We scope the first version, give you a fixed price, and build it in short steps. Fixes are free during the fix period after launch, and we stay on hand as it grows, because you want us there, not because you can't leave.

Read more on why Lephlo. To size a first version, try the Build Scope Planner, or book a free consultation.

Frequently asked questions

What is vendor lock-in? When switching away from a software supplier is so costly or risky that you effectively can't, because of how your code, data, contracts or processes depend on them.

Is all lock-in bad? No. Using a good accounting package means some dependence on it, and that's fine. The problem is lock-in you didn't choose, didn't price in, and can't get out of when you need to.

Can I export my app from a no-code platform? It depends on the platform. Some export only data, some export designs, and a few export code. Check before you build anything critical.

How do I make sure I own the code an agency writes for me? Put it in the contract: copyright assigned to you on payment, the code kept in a repository you control, and documentation included.

Sources