Vendor lock-in
Vendor lock-in is the situation where leaving a supplier costs more than staying, even when staying has become a bad deal. It is not a single feature but the accumulated cost of migrating your code, your data, your integrations and your users somewhere else.
Where the cost actually sits
It helps to separate the layers, because they have very different exit costs:
- Code. Do you have files you could host elsewhere, or does the application exist only as configuration inside a platform? See source code export.
- Data. Can you get a complete, structured export including relations and files, or a CSV of the main table and nothing else?
- Runtime and services. Proprietary functions, a bespoke authentication system, a database SDK unique to the platform. Each is a rewrite, not a copy.
- Identity. Users on
yourapp.platform.comcannot follow you. A custom domain with your own DNS is one of the cheapest and most effective protections available. - Knowledge. Skills and tooling that only apply to this vendor make the team itself part of the lock-in.
Why it is not simply bad
Some lock-in is the price of leverage, and refusing all of it means building everything yourself. A managed database, a hosting provider and a payment processor all create dependencies, and they are usually worth it. The distinction that matters is whether the dependency has a standard shape. Postgres is a dependency you can move between providers; a proprietary data store with a similar feature list is one you cannot. Standard HTML, JavaScript and a documented API are portable. A visual workflow engine is not.
The honest framing is therefore not "avoid lock-in" but know what leaving would cost, and pay a little now to keep that number bounded.
What to watch out for
Being given the source code is not the same as being able to leave. This is the misconception that catches the most people, and it is worth being concrete: an export that still calls the vendor's authentication endpoint, its database SDK and its AI proxy is a set of files that will not run anywhere without those services. Portability means the export runs somewhere else, and the only way to know is to try it — early, while switching is still hypothetical.
Three cheap habits that keep the cost down: own your domain, keep a working data export you have actually restored from, and put an interface in front of any vendor-specific SDK so replacing it touches one file. None of these is expensive at the start. All of them are expensive to add once the price rises or the vendor is acquired.
Frequently asked questions
How do I test whether I am locked in?
Try to leave, on a copy. Export the code and the data, run the application somewhere else, and log every call that fails. That list is your exit cost, expressed concretely instead of as a worry. Doing this once a year while the vendor relationship is still good is far cheaper than discovering it under pressure.
Build it yourself
NorthernGo turns a plain-text description into a working web app with a database, login and a live URL. Local AI generation runs on your own GPU, is unlimited, and is free on every plan.