AI App Builder Lock-In: What You Can Actually Take
Everyone asks whether they can export the code. The code is the easiest thing to take and the least valuable. The lock-in lives in the five layers underneath it.
"Can I export my code?" is the wrong first question about AI app builder vendor lock-in. Most platforms will hand you a repository, and the repository is the part you could most easily rebuild anyway. The expensive part of leaving is everything the code sits on: your database and its data, authentication and your existing users, third-party integrations, hosting and the deploy pipeline, and your domain and its accumulated trust.
Assessed layer by layer, the picture is more useful than a yes or no.
Portability, layer by layer
Layer | Typical portability | What actually bites |
|---|---|---|
Application code | Good, often a repo export | Code may be unidiomatic or lightly documented |
Database schema and data | Usually exportable | Proprietary field types, generated ids, no migration history |
User accounts | Partial | Password hashes rarely transfer, so every user resets |
Integrations | Fine | Keys and webhooks reconfigured by hand, one at a time |
Hosting and deploys | Rebuilt from scratch | The pipeline was the platform's, not yours |
Domain and SEO | Fully yours | Only if you registered the domain yourself |
Read that column of failure modes rather than the yes/no column. That is where the days go.
The authentication row is the one people underestimate. If a platform manages your users, moving means either migrating hashes, which needs the platform's cooperation and compatible algorithms, or forcing every user through a password reset, which costs you a measurable share of them. For an app with 50 users, an inconvenience. For one with 5,000, a real event you have to plan and communicate.
The database row is the second. Getting a data dump is usually easy. Getting a schema that a new stack understands, with the relationships and constraints intact and a migration history that lets you evolve it, frequently is not. Plan on a data modelling exercise, not a file transfer.
Why exported code is worth less than it sounds
An export gives you the code. It does not give you the ability to maintain it.
Generated codebases are often organised for the generator rather than for a person: helper functions inlined repeatedly, thin or absent comments, conventions that shift between files written in different sessions. It runs, and it is genuinely yours, and picking it up cold requires someone to read it properly before they can safely change anything. Budget for that reading, whether you are doing it or paying for it.
There is also a question of what "yours" means legally, which is separate from whether you have the files. Ownership of the generated output is usually addressed in the platform's terms, and the general position is covered in who owns AI-generated code. Check the actual terms rather than assuming, particularly for anything built on a free tier.
The five questions to ask before you build
Ask these before your first serious project on a platform, when the answers are cheap to act on.
Can I export the full source, on my plan, without asking? Self-service and included in the tier you are on. "Available on request" is a different product.
Where does my data live, and can I get a standard dump? A Postgres dump or equivalent you can restore elsewhere. If the database is proprietary and only reachable through their interface, that is your real lock-in.
Who controls my domain and DNS? Register the domain yourself, at a registrar you control, always. This costs nothing and removes the only irreversible item on the list.
How is authentication handled, and what happens to users if I leave? Ask specifically about password hash export. The answer is often no, and it is better to know that at the start.
What runs that I cannot see? Background jobs, scheduled tasks, email sending, file storage. These are invisible while they work and are usually the last things discovered during a migration.
A platform answering these clearly is a good sign in itself. Vagueness here tends to correlate with vagueness elsewhere.
Lock-in is a trade, not a trap
It is worth resisting the framing that lock-in is simply bad. You are buying integration, and integration is exactly why you can ship in a week rather than a quarter. Auth, database, hosting and deploys arriving pre-wired is the product. Some coupling is the price of that, and paying it is often correct.
The failure is not choosing a platform. It is choosing one without knowing the exit cost, then discovering it at the worst moment, usually when growth or a customer requirement forces a move under time pressure.
A proportionate way to think about it:
Validating an idea. Lock-in is close to irrelevant. If it fails you throw it away, and if it works you will rewrite things anyway. Optimise for speed.
A real product with paying users. Know your exit cost, keep the domain yours, and export your data periodically so a platform failure is recoverable.
Something with regulatory or enterprise requirements. Ask the five questions before writing anything, because a customer contract may eventually demand answers you cannot retrofit.
This maps onto the same reasoning as the wider limitations of AI app builders: the constraints are real and mostly acceptable, and problems come from not knowing which ones apply to you.
Reducing exposure without giving up the benefits
Four habits, none of which slow you down much.
Own the domain and DNS from day one. Export the database on a schedule and keep the dumps somewhere you control, which is worth doing for backup reasons regardless. Keep genuinely custom business logic in as few, as plain, and as well-separated a set of files as you can manage. And know roughly what your app would cost to rebuild, because that number is what your lock-in is actually worth, and it is usually smaller than people assume for an app under a year old.
If you are still deciding what to build on, the trade-offs against the alternatives are laid out in building an app with AI and, on the cost side, AI app builder versus hiring a developer.
FAQ
Which layer causes the most migrations to fail?
Authentication, followed by anything scheduled. Both are invisible during normal operation, which is precisely why they are missed in migration planning and then discovered live.
Is self-hosting from the start a way to avoid this?
It avoids platform lock-in and substitutes responsibility for infrastructure, security patching and deploys. For a team without that skill it usually means a slower launch and a worse operational position. It is a reasonable choice when you have the capability, and a poor default when you do not. Whether you need a backend at all is the prior question.
How often should I export my data?
Monthly for a small app, weekly once you have paying customers, and always before a significant platform change on your side. Automate it if the platform allows, and restore one of the dumps at least once so you know the export is actually usable.
Does exported code deploy anywhere?
Sometimes with small changes, sometimes not at all, depending on how much the generated app depends on platform-specific services for database, auth or storage. Assume you will replace those, and read deploying an app built with AI for what the destination side involves.
Should I pick a platform based on lock-in alone?
No. Pick on whether it builds the thing you need well, then use the exit cost as a tiebreaker and as input to how much you invest in it. A platform that ships your product and costs three weeks to leave beats one that never ships anything and costs nothing to leave.
How did this land?
About the author
Staff Engineer, Platform
Carlo works on the platform that turns prompts into running apps. He writes the engineering deep dives and the changelog notes worth reading.
