Every prompt-to-app builder says some version of "you own the code". Emergent puts it plainly: production-ready code you own, that you can download, modify or host anywhere you choose. That claim is true, and it is narrower than most people hear.
Owning the code is not the same as being able to leave, because an application is four layers and only one of them is code.
The four layers, and which ones travel
When a builder generates an app, you end up depending on four separate things. They have very different portability.
- Application code — usually yours, usually exportable, and genuinely the easiest layer to move. This is the one the marketing is about
- Data — your rows are yours, but the schema, the migrations and whatever the platform manages on your behalf may not come with them in a usable form
- Identity and permissions — if auth is a platform feature rather than a library in your code, it does not export. Rebuilding auth is one of the more expensive things a small team can be forced into
- Deployment and runtime — the code will run somewhere else, but the environment, the build pipeline, the secrets and the domain are usually reconstructed by hand
The export path is usually a paid feature
This catches people constantly. On Emergent, GitHub integration and private project hosting begin on the Standard plan, not the free tier — so a project built entirely on Free has no version history and no route out.
That is not unusual or dishonest; free tiers exist to demonstrate the product, and the export path is exactly the kind of thing that makes a paid tier worth paying for. It is only a problem when someone builds something real on the free tier assuming they can pull it down later.
The rule: if the project might matter, be on a plan with an export path from the start. It is the cheapest insurance in this category.
The test that tells you the truth
Do not read the documentation. Run the exit, once, while the project is still small.
Export the code. Clone it onto a machine that has never touched the platform. Try to run it. Write down every step where you had to go back to the platform for something — an environment variable, a database URL, a piece of configuration that only exists in their console.
That list is your actual lock-in. Not the vendor's claim, not your assumption: the specific things you could not reproduce. Most people find the code runs and the data layer does not, which is useful to learn in an afternoon rather than during a migration.
Do it again after any significant change in what the app depends on. The list only ever grows.
Lock-in is a price, not a sin
It is worth saying plainly: choosing a platform you cannot easily leave is often the right decision.
A visual platform that hosts, patches, backs up and secures your internal tool is doing real work that you would otherwise do badly at 11pm. If the app is a table with rules that eight people use, portability is a cost you are paying for a benefit you will never claim.
The mistake is not lock-in. The mistake is not knowing the price. Decide deliberately, write down why, and revisit when the app becomes something the business depends on — because that is when the calculation changes and nobody notices.
If you are already committed
You do not have to migrate to reduce your exposure. Do these instead, roughly in order of value.
- Get a data export running on a schedule, and restore one to prove it works. An untested backup is a belief, not a backup
- Document what only exists in the platform console — environment variables, integrations, scheduled jobs, permission rules. This is the part that actually blocks a migration
- Keep a copy of the generated code in your own repository, even if you never build from it. It is the difference between a migration and a rewrite
- Make sure at least two people have administrative access, and that access survives someone leaving
- Ask what your plan does about audit logs and data location before somebody in compliance asks you