I Cannot Get My Code Out of the Builder

You built the thing, it works, customers pay for it — and now you want it on your own infrastructure. Maybe the platform bill got silly, maybe an enterprise buyer asked where the code lives, maybe you hired an engineer who needs a repo to work in.

So you look for the export button and find one of three answers: there isn't one, there is one but it produces something unrunnable, or there is one and it costs an upgrade.

Before you panic, get precise about what you are actually missing. "I cannot get my code out" almost always means one of four different problems, and only one of them is genuinely hard.

What you are missing is probably not the code

An application is four things: the interface, the business logic, the data, and the runtime configuration. Builders differ enormously in which of those they hand back.

The distinction that matters: some platforms store your app as code, and some store it as configuration for their own engine. If yours is the first kind, this is an extraction job. If it is the second, it is a rebuild of the logic with the data carried across — and pretending otherwise wastes weeks.

For the code-generating tools, there is usually a path even when the UI is unhelpful — see the specifics for exporting code from Lovable, which apply in shape to Bolt and Replit too.

Get the data out first, today

Whatever else is true, your data is the part you cannot recreate. Do this before you negotiate, downgrade, or cancel anything:

1. Take a full export in the most structured format offered. A SQL dump beats CSV; CSV beats a screenshot. If only CSV is available, take one file per table and keep the ID columns.
2. Record the relationships. Exports frequently drop foreign keys, leaving you with orphan rows and no way to know which order belonged to which customer. Write down the schema while you still have the dashboard open.
3. Export uploaded files separately. Images and documents usually live in the platform's storage, referenced by URL. Those URLs die with the account. Pull the files and keep a mapping.
4. Capture the parts configured in a dashboard. Auth settings, roles, scheduled jobs, webhooks, email templates, and access policies are code even when they look like checkboxes. Screenshot everything and write it into a document.
5. Automate it if it is more than trivial. If the platform has an API, one throwaway script beats forty manual clicks and gives you a repeatable dry run.

Set a calendar reminder to repeat the export weekly until you have actually migrated. Platforms change plans and sunset products with short notice — Firebase Studio's wind-down caught a lot of people mid-build — and a stale export is worse than none because it feels like safety.

When the export runs but the app does not

This is the most common outcome for AI builders, and it is the one founders misread as failure. You get a repo, you run the install, and nothing works. That is expected. The export gives you the source but not the environment around it.

The usual gaps, in the order you will hit them:

• Secrets. Every key lived in the platform's settings. You need a local env file and a set of production variables at your new host. If that step misbehaves, environment variables that work locally and not in production covers it.
• Backend functions. Edge functions, serverless handlers, and scheduled jobs are often stored outside the repo. Copy them out of the dashboard by hand.
• Database connection. The exported app points at a database instance tied to the platform account. Stand up your own, load the dump, repoint the connection string.
• Auth. Hosted auth is the stickiest piece. You can usually migrate users with hashed passwords if the provider exports them; if not, plan a password reset flow for everyone.
• Build and deploy. No build command, no runtime version pinned, no CI. This is a day of work, not a blocker — deploying to Vercel is the shortest path for most generated frontends.

Budget a week for a small app to go from "exported" to "running on our own infrastructure with a deploy pipeline." Two to four weeks if the app has real users you cannot take offline while you do it.

When there is genuinely no export

If your logic lives in a visual runtime, accept it and plan properly. The work is to specify what the app does, rebuild it in code, and move the data — and the specification is the part you already own, because you built the app.

The approach that works:

• Inventory every screen and every workflow. Screenshot each one and write the rules in plain language. This document is the actual asset.
• Rank by usage. Most builder apps have a handful of flows that carry all the value and a long tail nobody touches. Rebuild the handful.
• Rebuild against the exported data, so you are validating with real records from day one.
• Run both systems in parallel briefly, with the old one read-only, then cut over.

That is the shape of a Bubble-to-code migration, and it is more predictable than it sounds — you are not designing a product, you are transcribing one that already works.

Avoiding this next time

Two questions answer most of it before you commit to a platform: can I get a running repo, and can I get a database dump. If both answers are yes, you have an exit. If either is no, price the platform as a permanent dependency rather than a starting point. AI builder lock-in breaks down where each tool sits on that spectrum.

Frequently asked questions

Does the platform own my code? Read your terms, but in most cases you own what you created and the platform owns its runtime, components, and templates. The practical constraint is rarely legal — it is that the code was never written in a form that runs anywhere else.

Can I scrape my own app to recover it? You can recover the visible markup, which is worth something for design reference and worth nothing for logic. Server-side rules, permissions, and integrations are not in the HTML. Treat scraping as a shortcut for pixels, not for behavior.

How much does getting out usually cost? For a code-exporting builder, extraction and hardening typically lands in the low thousands and a few weeks. A full rebuild off a visual runtime is a bigger number driven entirely by how many workflows you truly need — which is why the inventory step comes first.

---

If your app works but lives somewhere you cannot leave, the exit is a project with a scope, not a button. SprintX extracts apps from builders, migrates the data, and gets them running on infrastructure you own — with the deploy pipeline included. Send us your builder link and we will map the exit.