How to Spot Vendor Lock-In Before You Sign the Contract

The best time to spot vendor lock-in is before you sign, not eighteen months later when leaving costs more than staying. Lock-in almost never shows up in the fine print. It hides in the defaults: proprietary APIs, managed services with no open equivalent, data formats you cannot export cleanly, and a bill that grows faster than your usage. If you can answer one question, "how much does it cost me to leave," you already know most of what you need.

I run around twenty companies on infrastructure I control. Every one of them can move. That is not luck. It is a checklist I run before any dependency gets to touch production.

What does vendor lock-in actually mean

Lock-in is the gap between what a vendor charges you today and what it would cost to walk away. A small gap is fine. Every tool has some switching cost. The problem is when that gap grows quietly until the vendor can raise prices, degrade service, or change terms and you have no move.

There are three flavors. Data lock-in: your records live in a format only they read. API lock-in: your code calls their proprietary endpoints, not an open standard. Operational lock-in: your team only knows how to run things their way. The dangerous vendors give you all three at once, wrapped in a great onboarding experience.

How to spot lock-in before you sign

Ask for the export. Not the marketing promise of an export, the actual file. If you cannot get a full dump of your data in an open format on day one, you will not get it on the day you want to leave. I test this during the trial. If the export is partial, throttled, or "available on request," that is your answer.

Read the pricing for growth, not for today. Lock-in loves a low entry price and a steep curve. The cheap tier gets you committed. The bill climbs as you scale, and by then rewriting is expensive. I wrote more about that pattern in why your cloud bill climbs. Model your cost at ten times your current load before you sign anything.

Check whether an open equivalent exists. If the vendor runs Postgres, Redis, or plain Linux underneath, you can rebuild that yourself. If they invented a proprietary datastore with no export path, you are trapped by design. Managed Postgres is a convenience. A proprietary graph engine with a closed query language is a cage.

Count the proprietary API calls in your codebase. Every one is a line you rewrite to leave. Standard protocols, S3-compatible storage, SMTP, plain HTTP, these travel. Vendor-specific SDKs do not.

Why self-hosting kills most lock-in outright

The cleanest way to never worry about an exit is to own the box. When you deploy to your own server, there is no vendor between you and the metal that can hold your app hostage. You control the runtime, the data, and the deploy. I laid out what that looks like in what a deploy you actually control looks like.

This is the whole reason I built on HostSSH. I wanted deploys and hosting I own end to end, where moving a workload is a config change, not a migration project. When the underlying stack is standard Linux and open tooling, portability is the default state, not a feature I have to buy back.

Self-hosting is not always the answer. Sometimes a managed service is the right call and the lock-in is worth it. The point is to make that trade on purpose, with the exit cost in front of you, not to sleepwalk into it because the setup was smooth.

The exit-cost checklist to run first

Before any vendor touches production, I answer these in writing:

• Can I export all my data today, in full, in an open format?
• Does an open-source or self-hostable equivalent of this service exist?
• How many lines of my code call this vendor's proprietary API?
• What does the bill look like at ten times current usage?
• If they doubled prices tomorrow, what is my realistic move and how long does it take?

If the answers add up to a cheap, fast exit, sign with confidence. If leaving would take a quarter of engineering time and a rewrite, negotiate harder or walk. The mistake is treating the contract as the risk. The contract is downstream. The real risk is architectural, and it is set the day you choose the dependency.

Own the parts that would be expensive to leave. Rent the parts you could replace in an afternoon. That single rule has kept my whole portfolio movable, and movable is the only kind of leverage that survives a vendor's bad quarter.