You keep hearing the phrase "vendor lock-in." Maybe a comment on your app, maybe a warning in a forum thread, maybe a nagging worry when your no-code platform raised its price. But nobody ever tells you what it actually means for your app, or how to tell whether yours is a small annoyance or a real problem waiting to happen.
Here's the good news: lock-in is not a vague feeling. It's a cost, and costs can be measured. By the end of this post you'll have a plain-English definition and a simple way to score how locked in your app is, so you can stop guessing and start with a number.
In Plain English: what vendor lock-in actually is
Vendor lock-in is the cost of leaving a tool. That's it. It's how much time, money, and effort it would take to move your app off the platform, service, or tool it currently runs on and onto something else.
Notice what this definition does not say. It doesn't say using a tool is lock-in. Every tool you pick creates some attachment, and that's normal. You built on a platform because it saved you months of work. The question isn't whether you depend on a tool. You do, and that's fine. The question is: if you had to leave, how painful would it be?
A quick way to feel the difference:
- Low lock-in: You could export your data as a clean file, and the same work could be rebuilt on another tool in a weekend.
- High lock-in: Your data lives in a format only this tool understands, your app's logic is tangled into features no one else offers, and rebuilding it elsewhere would take weeks and a skill you don't have.
Both apps "depend" on their tools. Only one of them is expensive to leave. Lock-in is about the leaving, not the using.
The four hidden costs: data, logic, skills, and contracts
The reason lock-in feels abstract is that the cost hides in four different places. When you break it apart, each piece becomes something you can look at directly.
1. Data portability
Can you get your data out, and is it usable once it's out?
Your users, orders, posts, records: all of it lives somewhere. Some tools hand you a clean CSV or a standard export with one click. Others let you export something, but it comes out as a tangled mess that would need real work to import anywhere else. And a few make it genuinely hard to leave with your own data at all.
Ask: If I hit "export" today, what do I get, and could another tool actually read it?
2. Logic portability
Your app doesn't just store data. It does things: sends an email when someone signs up, calculates a total, shows different screens to different users. That behavior is your logic.
In a no-code tool, that logic is often built out of the platform's own blocks, automations, and settings. It works beautifully inside that tool and doesn't exist as anything you can carry out the door. Moving it means rebuilding it from scratch somewhere else.
Ask: If I switched platforms, how much of what my app does would I have to recreate by hand?
3. Skill and relearning cost
Even if your data and logic could move, someone has to do the moving, and that someone is usually you.
If the new tool works like the old one, the relearning cost is low. If it's a completely different way of building (say, moving from a visual builder to something that expects a bit of code), you're paying in weeks of learning, or in what a professional would charge to do it for you. This cost is easy to forget because it's not on any invoice, but it's real.
Ask: Do I already know how to use the alternative, or would I be starting over?
4. Contractual and financial cost
Finally, the paperwork and the money. Some plans have annual commitments, cancellation terms, or fees tied to exporting or migrating. Sometimes leaving means losing an integration or a grandfathered price you can't get back.
This one comes with a caveat: contract terms are specific to each vendor and they change. Do not assume. Check your current plan's actual terms before you count on them.
Ask: What does my agreement actually say about leaving, and when did I last check?
Why some lock-in is fine and some is a real risk
It's tempting to treat lock-in as a villain. It isn't. Lock-in is a tradeoff you chose, usually for good reasons. Platforms that do a lot for you tend to be harder to leave precisely because they do a lot for you. That convenience is what let you ship in the first place.
Think of it as a spectrum, not a pass/fail:
| Lock-in level | What it feels like | When it's fine | When to pay attention |
|---|---|---|---|
| Low | You could leave in a weekend | Almost always | Rarely a concern |
| Medium | Leaving would take real effort but is doable | Fine if the tool serves you well | Watch for price hikes or shrinking fit |
| High | Leaving would be a major project | Fine while the tool is a great fit | A risk if the tool declines, prices spike, or your needs outgrow it |
High lock-in isn't a mistake. It becomes a risk only when it meets a trigger: the vendor raises prices sharply, changes direction, gets acquired, shuts down, or simply stops fitting what you need. If none of that happens, high lock-in can sit quietly forever and cost you nothing.
The point of measuring it isn't to feel guilty or to rush into a migration. It's to know your exposure before a trigger shows up, so any decision you make is calm and informed. There's no prize for the lowest score. For a wider look at what "owning" your app really involves, this fits inside the bigger question of whether do you actually own your app?.
How to score your lock-in across each dimension
Here's the simple part. Rate each of the four dimensions from 1 (easy to leave) to 5 (very hard to leave), then add them up. Your total lands between 4 and 20.
Use this rough guide for each score:
- 1-2: Standard export, portable logic, familiar alternative, no contract friction.
- 3: Doable, but with some manual work or learning involved.
- 4-5: Proprietary formats, heavy platform-specific logic, a big skill gap, or contract terms that make leaving costly.
Add the four numbers:
- 4-8: Low lock-in. You have good freedom of movement.
- 9-14: Medium lock-in. Leaving is a project, not a catastrophe.
- 15-20: High lock-in. You're deeply tied in. Fine for now, worth watching.
A worked example
Say you built a small booking app on an all-in-one no-code platform.
| Dimension | Your situation | Score |
|---|---|---|
| Data portability | Bookings export as a clean CSV | 2 |
| Logic portability | Your booking rules and automated reminders are built entirely from the platform's blocks | 4 |
| Skill / relearning | You only know this platform; alternatives look very different | 4 |
| Contract / financial | Month-to-month, no exit fees (verified on your current plan) | 2 |
| Total | 12 |
A 12 puts this app squarely in medium lock-in. The read is clear: your data would come out fine, but your logic and your own skills are what tie you down. That tells you exactly where to focus if you ever want to lower the score. You'd work on making the logic more portable and getting comfortable with an alternative, not on the data, which is already fine.
That's the whole value of scoring. It turns "I feel uneasy" into "my exposure is in logic and skills, and here's the number." Run the same four rows on your own app and you'll get your own answer.
What your score means and what to do next
A score is a starting point, not a verdict. Here's how to read yours.
- Low (4-8): Nothing to do. Note it and move on. Revisit if you add major new features tied to one tool.
- Medium (9-14): No emergency. Do the cheap, boring insurance now: make sure you can export your data and code on demand, and keep a plain note of how your key logic works so it isn't trapped only in the tool.
- High (15-20): Still no emergency if the tool fits you well. But keep an eye on the triggers (price, direction, fit), and understand your options before you need them. If you ever do decide to move, it's worth knowing how to migrate off a tool without downtime.
Whatever your score, the most common way people end up more locked in than they meant to is by accident, one small convenient choice at a time. If your number came out higher than you expected, 7 ways solo builders accidentally lock themselves in will probably explain how you got there.
In Plain English
What it means: Vendor lock-in is the cost of leaving a tool, and that cost lives in four measurable places: your data, your logic, your skills, and your contract. Score each from 1 to 5, add them up, and you have a low/medium/high read on how tied in your app is.
Who it helps: Solo builders and non-technical founders who keep hearing "lock-in" and want a straight answer about what it means for their own app instead of a lecture.
When to use it: Any time you feel uneasy about how dependent your app is on one platform, or before you make a big new commitment to a tool, sign a longer plan, or consider switching.
What to do next: Score your four dimensions. If the total is low, relax. If it's medium or high, do the cheap insurance (confirm you can export, write down your logic) and re-check your contract's actual terms, because those change.
Turn your definition into a number
Now that you know what lock-in is and how to break it down, put a real number on your own app. Run your four dimensions through the Lock-in scorecard, then see how it fits into the bigger picture over at the Own Your Stack hub. If you're not sure what a term above meant, the Glossary has plain-English definitions for the rest.
No migration required. Just clarity about where you stand.
Kodbe is an independent commercial publication about maintaining and owning software built with AI or no-code tools. It is not affiliated with Kodbe Inc, Kodobe, Kodable, or Kodu.