Platform vendor lock-in: what you can actually export

**Short answer:** it varies more than the marketing suggests. Bubble hands you your data and no code, by design. Retool git-syncs your apps as Toolscript that only runs in Retool. Lovable, Bolt and v0 give you the code and sync it both ways with GitHub. Supabase gives you Postgres and your own application code. We give you a readable directory of Python and JavaScript, **one-way**, and the running app still calls us for auth, data and logic unless you self-host the platform. The table is below. We are not the best row in it.

---

schemas.py, ui_schemas.py, config.py, setup.py, ui/app.js, run.sh.

That is what you walk away with — a directory of readable Python and JavaScript your team can open, diff and host. Download it as a tarball today, or push it to a GitHub or Bitbucket repo you own.

One thing to be clear about, because it shapes what the artefact is. Generation is not reproducible. Two runs from the same input measured 0.635 similarity on ui/app.js, so about 36% of that file moved between them — and that path already requests temperature=0.2, under a router defaulting to 0.0, with no seed pinned anywhere. Low temperature does not make a multi-step generation reproducible. So the tarball is *that run*: a specific directory you can read, diff and host, and not a build you can recreate by generating again.

Now the parts most vendors leave out.

**The source leaves; it does not come back.** You cannot edit on GitHub and have changes flow into the live app. An ingestion path exists but is opt-in, gated and deliberately fails closed at every step. Fork it and you have forked it. You maintain it from then on, off-platform.

**The runtime is ours, and that is the real lock-in.** Take the source, host the UI on your own AWS or GCP, and auth, data, logic and AI still call Supero. Those are the platform, not your app's code. Full independence means the on-premise deployment: a Debian package with offline licence validation, built for air-gapped environments. It exists, and it is an Enterprise arrangement. We have not yet published a runbook from a customer who has actually done it, so treat it as documented-and-shipped rather than independently proven.

So: **your application is portable. The governance layer is the product.** If that trade is unacceptable, stop reading. We are not your platform, and I would rather you worked that out here.

---

We are in the middle, and on the code-access axis specifically the AI builders beat us: their sync is two-way and ours is not. What you buy with that difference is a governance layer you would otherwise write: the isolation model and the field-permission enforcement. If you do not need those, their trade is better than ours and you should take it.

We are designed for SOC 2 and HIPAA controls and certified for neither, and we are early access with the rough edges that implies. On the governance side: access policy is permissive by default inside a tenant, and we log writes but not reads. Every weakness we know about. On a page about what you can verify, it would be poor form to summarise our own weaknesses and leave you no way to check the summary.

---

Portable regardless of what you choose. This is the part of the page worth stealing.

1. **Name the artefact.** What is the file, and have you ever downloaded it? A capability nobody has exercised is a capability nobody has verified. 2. **Where does the data live, and can it live somewhere you control?** 3. **What still calls the vendor after you export?** The question people forget, and the one that determines actual lock-in. 4. **Is there a self-host path, and is it real** — a shipped deployment, with a customer who has done it? 5. **Does the export path get exercised?** An untested export is a claim, not a capability.

I have answered our #4 with more precision than our #5, deliberately. If a vendor, us included, answers #4 with the word "yes" and nothing after it, that is the answer to a different question.

---

No. Bubble's stated position is that the app exists inside Bubble and does not leave. You can export your data; you cannot export the application.

Retool has Source Control: apps check into GitHub, GitLab, Bitbucket, Azure Repos or CodeCommit as Toolscript. Retool's pricing table lists it under **Enterprise only**, so it is not available to a Business-tier team. The artifact is real and version-controlled, and it runs inside Retool.

Yes, with two-way GitHub sync. Access differs by tier: Bolt provides a zip on any plan, Lovable's full download is paid-only, and v0 works on branches in a repo you own.

Yes. A readable directory of Python and JavaScript, as a tarball or pushed to your own GitHub or Bitbucket. One-way: the source leaves, it does not flow back.

You hold the source. The running app calls our backend for auth, data and logic, so continuity means either the on-premise deployment or rebuilding that layer. That is the honest shape of the risk, and it is why question 3 above matters more than question 1.

No. In live connector modes we query your own database and copy no column or row data into ours.

---

**Ask your current vendor the five questions.** That is the useful thing on this page and it costs you nothing.

An export is worth what the thing it exports is worth. **sixteen platform-generated apps are live and need no account.** The full list is at api.supero.dev/api/v1/public/showcase. All but two are single-tenant public demos, so they show the generated application rather than the governance. If the output is the standard you would ship, request access and download a bundle before you commit to anything. Question 1 applies to us too, and nobody should get a pass on it.

---

*Competitor export behaviour checked **September 2026**. This changes; corrections welcome.*