How to export an app from an AI app builder

Export the code, and you have roughly a quarter of your application. That is the thing worth knowing before you start. How to export an app from an AI app builder is less a download problem than an inventory problem: five things have to come out for the app to run somewhere else, and three of them are usually not in the zip file.

This is the order to do it in, and the checks that tell you it worked.

To export an app from an AI app builder, five things must come out

Work down that list before touching anything else. The most common way a migration fails is not a technical wall, it is discovering in week two that the data export needs an account that has already been cancelled.

Step 1: take the inventory while you still have access

Do this before you decide to leave, ideally the week you start relying on the platform. Fifteen minutes.

1. Screenshot or copy every environment variable and secret from the settings panel. Store them in a password manager, not a text file.

2. List every third-party integration the app uses: payments, email, storage, authentication, analytics. Note which are configured inside the platform rather than in code.

3. Note the runtime version and the framework, exactly. "Node" is not an answer, "Node 22" is.

4. Find the data export path and run it once, now. Do not assume one exists because the marketing page mentions ownership.

That last one is the whole test. A platform that lets you download code but not your production data has given you a template, not your application.

Step 2: export the code, then read it

Get the code out, into your own git repository, before changing anything. Then read enough of it to answer three questions:

• Does it call any URL belonging to the platform? Hosted builders frequently route storage, auth or email through their own endpoints, and those calls stop working the moment you leave.

• Are database credentials in the code, in a config file, or injected at runtime by the platform? The third case means the code has no idea how to connect on its own.

• Is there a build step you have never run? If the platform compiled it for you, you will be running that command for the first time on your own machine.

You do not need to understand every file. You need to find the places where the app assumes it is running inside the platform, because those are the edits the migration actually consists of.

Step 3: get the data out properly

Data export is where migrations stall, and the shape of the problem depends on what is underneath.

If the platform gave you a real Postgres or MySQL database, ask for connection details and take a normal dump with pg_dump or its equivalent. That is the good case, and it is one of the reasons choosing a database for an AI-built app matters more than it seems at the time.

If storage is proprietary, you are exporting through whatever the platform offers, usually CSV or JSON per table. Two things to check before trusting it: that relationships between tables survived, meaning the foreign keys still point at rows that exist, and that files are included. Uploaded images and documents are stored separately from records almost everywhere, and an export containing filenames but no files is a very quiet kind of data loss.

Restore the export into a fresh local database and count rows against the live app. Not a spot check, actual counts per table.

Step 4: stand it up somewhere else

Now the ordinary work. Point the code at your restored database, supply the environment variables from your inventory, and get it running locally before you think about hosting. Local first, always: debugging a deployment and a migration simultaneously is how a two-day job becomes a two-week one.

Once it runs locally, deploying is the same job as any other application, and the usual paths in how to deploy an app built with AI apply unchanged. Expect the integrations to be the slow part: payment webhooks pointing at the old domain, email sending from a verified address you did not control, authentication callbacks registered against the platform's URL.

The three things that never export

1. Managed infrastructure behaviour.

   Automatic scaling, backups, TLS certificates and the CDN in front of your app were the platform's job. They are now yours, and backups are the one people forget until they need one.

2. The builder itself.

   You keep the code you have. You lose the ability to describe a change in a sentence and have it implemented. If that was how the app was maintained, plan for who maintains it now.

3. Undocumented platform behaviour.

   Cron jobs configured in a UI, redirects set in a dashboard, rate limits applied at the edge. None of it is in the repository, and you will find it by discovering something stopped happening.

None of this argues against building on these platforms. It argues for knowing what the exit costs before you need it, which is the practical half of what AI app builder lock-in really costs.

How to prove the export worked

Run these four checks before shutting anything down:

• Row counts match, per table, between the old app and the new one.

• A file uploaded on the old system opens on the new one.

• A full user journey works end to end on the new deployment: sign in, do the main thing, receive whatever email it sends.

• Both systems run in parallel for at least a week, with the old one still reachable.

Keep the old account alive for a month past the cutover. It costs one more invoice and it is the only way to recover something you did not realise you needed.

If a developer is taking over at this point, the handover is its own exercise, and handing off an AI-built app to a developer covers what they will ask for. Either way, an app that survives an export is a real application rather than a hosted artefact, which is a reasonable ambition for anything built through building an app with AI that you intend to keep.

FAQ

Can I always export the code from an AI app builder?

Most mainstream builders offer code download or a git connection. Check the specific platform's documentation rather than assuming, and check it before you depend on the app, not after.

Does exported code actually run outside the platform?

Not without edits, usually. Expect calls to platform-hosted services for storage, authentication or email, plus configuration the platform injected at runtime that now has to come from somewhere.

What about my data?

Export it separately and verify it. Check that table relationships survived and that uploaded files came with the records, because an export of filenames without files is a common and quiet failure.

How long does a migration take?

For a small app with the inventory already done, a couple of days. Without the inventory, budget a week or more, most of it spent rediscovering configuration that only existed in a dashboard.

Should I export before I need to?

Do the inventory early and run one test export. The migration itself can wait, but discovering that the data export does not exist should not happen on the day you need it.