Exporting and owning your AI-built code

Symptom

You download the project, unzip it, run npm install && npm run dev, and get a blank page. The browser console says:

Or it runs, but you can't log in, the lists are empty, and uploaded images are missing. Or a developer you have hired asks for "access to everything" and you realise you are not sure what everything is.

The code came out. The app did not.

Why it happens

An AI-built app is more than its source files. When you export, you get the code. What stays behind:

• Secrets and environment variables. API keys, the database URL, the Stripe key. These sit in the tool's secrets store, deliberately outside the code.
• Data. Users, records and uploaded files live in the database and file storage, not in the repository. Lovable's docs say the code includes migration files describing the database structure, but data and uploaded files are exported separately.
• Service settings. Auth redirect URLs, email templates, webhooks, scheduled jobs, domain records.
• Accounts. If the database, payment provider or domain is registered under the tool or under someone else's login, you don't control it, whatever the licence says.

Each tool also exports differently, and the differences matter.

Bolt

• Download: click the project title in the top left, then Download. Vercel's guide describes the same menu as Export, then Download. It is desktop only. Bolt's docs suggest running npm install && npm run dev after unzipping.
• What is missing: Vercel's guide says Secrets panel values are not in the export.
• GitHub: only the project owner can connect. Bolt creates a private repository on main, commits changes that don't break the project, and checks GitHub every 30 seconds for changes made elsewhere. The project always stays on main: you can create other branches in GitHub, but you can't switch the Bolt project to one.
• Watch out: disconnecting a project from GitHub is permanent. You can't reconnect it yourself.
• Data: Bolt's database Tables page can export row data. To move the whole database, Bolt documents a Claim option into your own Supabase account, on Pro or Teams plans.

More detail in exporting code from Bolt.

Lovable

• GitHub: Lovable always creates a new, private repository and syncs both ways on one branch, usually main. If a push is rejected, for example by branch protection, it pushes to a lovable-sync branch for you to merge.
• Download: Download codebase, under Project settings, Git, on paid plans. It is a one-off snapshot.
• Transfers: moving the repository to another GitHub account or organisation keeps sync running only if your Lovable workspace has a GitHub connection for the new owner.

More in exporting code from Lovable.

v0

• GitHub: Project menu, Settings, GitHub, then Connect. v0 creates a private repository and pushes the current code. From then on, v0's docs say the repository is the source of truth, and deleting it may make the code unrecoverable.
• Branches: v0 makes its changes on a separate working branch, and each working branch gets its own Vercel preview. Publishing opens or reuses a pull request into your base branch, merges it and waits for the production deployment.
• API: v0's API reference also documents a download endpoint for a chat version, as a zip or tarball.

More in exporting code from v0.

Replit

• Download: the three-dot menu at the top of the file tree, then Download as zip. If the download fails, Replit suggests running zip -r project.zip . in the Shell and downloading that file instead.
• GitHub: link GitHub in your account's connected services, then connect the repository in the Git tool. Replit says a fine-grained personal access token is more reliable.
• Watch out: Replit's docs say the .cache folder holds cached secret values. Exclude it from any zip you make by hand. Secret values, including deployment secrets, never leave the original project, and Replit notes that the development database is usually not where your live data is.

More in exporting code from Replit.

The fix

Owning the app means you could run it somewhere else tomorrow without the original tool. Here is how I get a project to that point.

1. Put the code in a repository you control

Use Git sync, not a zip, so history comes with it and future changes keep flowing. Create a GitHub organisation for the business, even if you are the only member, and make sure the repository ends up there. That way access survives a falling-out with a freelancer, including me.

2. Run it locally from a clean clone

git clone git@github.com:your-org/your-app.git
cd your-app
npm ci          # uses the lock file, so versions match what the tool built
npm run build   # catches errors the dev server hides
npm run dev

If npm ci complains that there is no lock file, run npm install once and commit the package-lock.json it creates.

3. Write down every variable the code reads

grep -rhoE "import\.meta\.env\.[A-Z0-9_]+|process\.env\.[A-Z0-9_]+|Deno\.env\.get\(\"[A-Z0-9_]+\"\)" . \
  --include='*.ts' --include='*.tsx' --include='*.js' --exclude-dir=node_modules | sort -u

Turn the result into a .env.example with names and no values, and commit it. Keep the real values in a password manager or your host's secrets store.

# .env.example
VITE_SUPABASE_URL=
VITE_SUPABASE_PUBLISHABLE_KEY=
STRIPE_SECRET_KEY=
STRIPE_WEBHOOK_SECRET=

4. Export the data

Export the database and the stored files, then check the export by restoring it somewhere. For a Supabase project you control, Supabase's CLI guide uses supabase db dump for roles, schema and data. It notes that storage objects and Edge Functions need moving separately. For Lovable's built-in backend, Lovable's docs say to export the database and download storage files, and to verify them before retiring anything.

5. Record the settings that are not in code

A plain document in the repository is enough. Auth providers and redirect URLs, email sender settings, webhook endpoints, scheduled jobs, domain records and which secrets exist. This is the list a developer would otherwise spend days rediscovering.

6. Move accounts into your name

The database project, Stripe account, email provider, domain registrar, analytics and hosting should all be owned by an account that belongs to the business. Add others as members. Don't share one login.

How to prevent it

• Connect Git sync on day one, not the week before launch.
• Never paste secrets into chat or code. Use each tool's secrets store, and rotate anything that leaked.
• Keep .env.example and the settings document updated as the app changes.
• Rehearse a restore of your data before you need it.
• Be deliberate about where you edit. With two-way sync in Lovable and Bolt, a prompt can overwrite a fix made in code.

Once the code is yours, moving off Lovable or Bolt hosting is the natural next step, and the launch checklist for AI-built apps covers what to check before real users arrive. The bigger picture is in the prototype to product guide.

When to get help

If you can't run the app from a clean clone, or you don't know which accounts it depends on, sort that out before you take on paying users. It only gets harder.

Getting a project into a repository you own, running locally and documented is the first thing I do in a Rescue Sprint. The free health check gives you a quick read before you book a call.