Vendor lock-in: what it costs and when to accept it

Vendor lock-in is not a bug to avoid. Every tool you adopt sells you speed today in exchange for optionality tomorrow, and the job is to price that trade before you sign it.

A logistics founder we worked with built his entire operations portal on a no-code platform. Six weeks of work, and it ran the business well for two years. Then his largest prospect put single sign-on and an exportable audit log into the contract as conditions of signing. The platform could do neither. Rebuilding took five months, and the shipper did not wait.

Vendor lock-in is the condition of depending on a vendor so heavily that leaving costs more than staying, even when staying is the wrong thing to do. It is not a hidden defect in bad tools. It is the natural byproduct of any tool that does real work for you, and it accumulates in four places: your code, your data, your workflows, and your people.

That founder did not get locked in because he made a bad decision. He got locked in because he made a good decision and never went back to check its price.

What vendor lock-in actually means

The textbook definition is about switching costs: proprietary formats, incompatible APIs, contractual penalties, the expense of migrating off one provider onto another. That definition is correct and almost useless, because it describes a condition that applies to literally every tool you will ever adopt.

Here is the more useful distinction.

You are not locked in when leaving is expensive. You are locked in when leaving is expensive enough that you stop considering it.

That is the line that matters. A switching cost is a number. Lock-in is what happens when the number gets big enough to start making your decisions for you: when you stop evaluating alternatives, when you route around a missing feature instead of demanding it, when you tell a customer no because your platform said no first. The logistics founder did not decide to lose that shipper. His stack decided for him, two years earlier, on a Tuesday, when nobody was paying attention.

The four locks

Lock-in is usually discussed as one thing. It is four, and they have very different prices.

Code lock. You cannot take the software with you, because there is no software to take. No-code platforms are the purest case: there is no artifact, no repository, nothing that runs anywhere except inside the vendor’s editor. Proprietary languages are the same trap wearing a suit. The moment your logic lives in a dialect only one company compiles, that logic is theirs.

Data lock. Every platform on earth will export your data. Almost none of them will export the shape of it. You get a CSV of your customers, and you lose the relationships between them, the permission model, the state machine your orders move through, the IDs that three other systems reference. The rows survive. The meaning does not.

Workflow lock. This is the one nobody prices, and it is usually the most expensive. Over two years your team quietly reshapes the business to fit the tool’s assumptions. Somebody invents a manual step because the platform cannot do a real one. That step becomes a habit, the habit becomes a process, and the process becomes how the company works. Now you are not migrating software. You are migrating an organization.

People lock. The only people who can maintain the thing are certified in the vendor’s ecosystem, which means you hire from a labor pool the vendor controls, at a price the vendor influences. When your one certified developer leaves, you do not go to the market. You go to the vendor’s partner directory.

Code lock is the loudest and the easiest to fix. Workflow and people lock are quiet, compound daily, and are what actually traps companies.

Lock-in is a price, not a defect

Here is the part the rest of the internet gets wrong.

Every abstraction you adopt locks you in. Postgres locks you in. React locks you in. Your accounting software, your payroll provider, the language your product is written in, the cloud your servers run on. The only way to own zero dependencies is to build everything yourself, which is a different trap and a much worse one.

So the question is never “am I locked in.” You are. The question is what you paid, and whether the thing you bought is worth it.

Joel Spolsky drew the line twenty-five years ago in In Defense of Not-Invented-Here Syndrome, and it has not moved since:

If it’s a core business function — do it yourself, no matter what.

That is the whole framework, and it converts cleanly into a rule about dependencies. Lock-in on a function that does not make you money is cheap, and you should welcome it. You do not want to own your payroll system. Be locked into Gusto. Be delighted about it. Lock-in on the system your margin depends on is existential, and no discount is large enough to justify it. If your pricing engine, your matching algorithm, or your underwriting logic lives inside somebody else’s product, you are not running a company. You are running a franchise.

Most founders get this backwards. They agonize over which CRM to buy, a decision they could reverse in three weeks, and then casually let the thing that differentiates them get built inside a platform they will never escape. The build vs buy decision is not about cost. It is about which side of that line the system sits on.

The exit cost test

Before adopting anything that will touch a core workflow, we run four questions. It takes twenty minutes and it is the cheapest insurance in software.

1. If we left in eighteen months, what physically comes with us?

Name the artifacts out loud: source code, database schema, data, documentation, domain, customer records, integrations. Write the list down. If the honest answer is “a CSV export,” you are not a customer. You are a tenant.

2. How many weeks, not how many dollars?

Price the exit in engineering weeks and business disruption, never in license fees. Dollars are recoverable. A five-month rebuild that lands in the middle of a fundraise is not. The logistics founder’s exit cost was not a number on an invoice. It was a quarter of a year and an enterprise logo.

3. Does our roadmap need their roadmap’s permission?

This is the sharpest question of the four. If you cannot ship a feature that differentiates you until the vendor decides to build it, you have not bought a tool. You have outsourced your product strategy to a company that has never met your customers and does not care whether you win.

4. Who else can maintain this?

If the answer is “certified partners of the vendor,” you have a supply problem disguised as a technology choice. If the answer is “any competent engineer who knows this language,” you are fine.

Score the four honestly. A tool that fails questions 1 and 3 is excellent for validation and dangerous as an architecture. That is not a contradiction. It is a schedule.

Where founders actually get locked in

Search for vendor lock-in and you will get ten articles about AWS egress fees and multi-cloud strategy. Useful, if you have an IT department. That is not where it bites a founder. Here is where it does.

The no-code platform you outgrew. It got you to a working product in six weeks, which was the right call. It cannot do SSO, audit logs, a real permissions model, or the one workflow your enterprise customer requires. Most founders overstay on no-code by six to twelve months, and the overstay is not a technology failure. It is a failure to have re-read the price tag once the company changed.

The software house that holds your repository. This is the one that ends companies, and it is almost always discovered at the worst possible moment. If your software development contract does not say that the code is yours, in a repository you own, from day one, then you do not have a technology partner. You have a landlord. Source code escrow exists precisely because this happens often enough to have generated its own legal instrument.

The data model bent around one provider. Somebody used a payment provider’s IDs as your primary keys. Somebody stored the state of an order in a field that only that provider writes to. Two years later, switching processors means rewriting the order system, and the order system is the company.

The internal tool nobody documented. One contractor built it, one contractor understood it, and that contractor is gone. You are not locked into a vendor now. You are locked into a legacy system with a headcount of zero.

When lock-in is the right trade

Often. More often than the cautionary articles suggest.

When you are still validating. If the company might not exist in a year, optionality is a luxury good you cannot afford. Lock in hard, ship in six weeks, and find out whether anyone wants the thing. Optionality you never exercise is money you set on fire.

When the function is not core. Payroll, email, accounting, the CRM your six-person sales team uses. Adopt the market leader, get locked in, and never think about it again. The mental overhead of staying portable on a commodity is itself a cost.

When the exit is genuinely reversible. If you can leave in under four weeks, that is not lock-in. That is a switching cost, and switching costs are normal.

Which gives the rule of thumb we use, and the only sentence in this article worth writing on a whiteboard:

Accept lock-in in inverse proportion to how close the system sits to your margin.

The further a system is from the money, the more lock-in you should happily take. The closer it gets, the more you should own outright. Almost every expensive mistake we get called in to fix is a violation of that one line.

How to avoid vendor lock-in without becoming paranoid

The opposite failure is real, and it is more common among technical teams than founders: building abstraction layers “just in case,” writing your own wrapper around every service, refusing managed infrastructure because someday you might move. That is a portability tax, and you pay it every single day for a migration that will probably never happen. The cost of premature portability is a rent. The cost of a migration is a mortgage. Rent is worse.

The proportionate version is short.

Own the repository, from day one, in an account you control. Own your data model, and understand it well enough to describe it in a sentence. Own the domain and the DNS. Export your data monthly and, at least once, actually restore the export somewhere else. An export you have never restored is not a backup. It is a belief.

Then put it in the contract: code ownership on day one, a data portability clause, and documentation as a named deliverable rather than a favor.

Regulators have started treating switching costs as a competition problem rather than a technical inconvenience. The EU’s Data Act, in application since September 2025, sets out a framework requiring providers of data-processing services to let customers switch, and prohibits contract terms that block data sharing. The direction of travel is clear: the right to leave is becoming something you are owed, not something you negotiate. That is good news, and it will arrive far too late to help you with the vendor you are choosing this quarter.

Common questions

What is vendor lock-in, in simple terms?

Depending on one vendor so heavily that switching away would cost more than staying, even when staying is hurting you. The cost can be code you cannot take with you, data you cannot meaningfully export, workflows built around the tool’s limits, or staff who only know that vendor’s ecosystem.

What is an example of vendor lock-in?

A startup builds its ops portal on a no-code platform. Two years later an enterprise customer requires single sign-on and an audit log. The platform cannot provide either, there is no source code to modify, and the only path forward is a five-month rebuild. The switching cost was invisible on day one and decisive on day seven hundred.

How do you avoid vendor lock-in?

You do not avoid it. You price it. Before adopting a tool, ask what physically leaves with you if you go, how many weeks the exit would take, whether your roadmap depends on the vendor’s roadmap, and who besides the vendor’s partners can maintain it. Then own the repository, own the data model, own the domain, and test your exports.

Is vendor lock-in always bad?

No. Lock-in on a commodity function is a good trade and usually a bargain. Lock-in on the system that produces your margin is a strategic error. The distance between the system and your revenue is what determines which one you are looking at.

The logistics founder rebuilt his portal. Five months, and he lost the shipper. When we asked what he would do differently, he did not say he would have skipped the no-code platform. He said he would have written down, on the day he adopted it, what it would cost to leave.

He never wrote that number down, so it grew quietly for two years, and he finally learned it on the one day it could not be paid.

Lock-in was never the problem. Not knowing the price was.