Field Notes

The Export Illusion: Why 'You Own the Code' Rarely Means You Can Leave

July 7, 2026
The Export Illusion: Why 'You Own the Code' Rarely Means You Can Leave

Every vibe coding tool with a GitHub button says some version of the same sentence: “you own your code, no lock-in.” It’s on the pricing page, in the FAQ, usually right next to a checkmark icon. Treat that sentence as a claim to verify, not a fact to accept, because the gap between “you can export a file” and “you can leave” is where most of the actual lock-in lives.

What “export” quietly leaves out

A codebase is not one thing. It’s a frontend, a backend, and a database, and a tool can advertise “code export” while only meaning the first of the three. Base44 documents this split plainly: front-end source exports to GitHub, but backend logic is hosted and managed entirely on Base44’s own infrastructure, described in its own materials as cannot be directly modified or exported. Product Hunt reviews of Base44 note the same shape from the user side, that the database and backend stay trapped in the platform’s closed infrastructure even though the frontend leaves cleanly. One Reddit user trying to actually get off the platform reported being quoted a year of the $40/mo Builder plan, $480, just to access source files after their app broke repeatedly under a debugging loop.

Zite skips the question entirely. It offers no GitHub sync path and no code export at all, which its own users flag on Reddit as a real obstacle when the time comes for migration or developer handoff. No export button means the “own your code” conversation doesn’t even start.

Exported code you don’t want

The other half of the illusion is assuming exported code is code anyone would choose to maintain. Lovable genuinely exports standard React and TypeScript, and syncs to GitHub for local development, which is a real strength. But its own user reports describe the result as messy and non-scalable: one builder summarized it as fine for a visual reference but not something to port cleanly, recommending a developer rebuild the app in a real stack rather than inherit the generated one. That’s consistent with the broader pattern this site tracks: the fix loop leaves behind duplicate utility functions and patchwork styles, because the model can’t see the whole codebase it’s editing. Export hands you that patchwork with a GitHub URL attached, not a codebase a new developer can pick up on day one.

The database side compounds it. Lovable users on Reddit have called the platform a “Hotel California” for your database: you can check in, but multiple reports describe the AI autonomously initiating a backend migration, from a builder’s private Supabase project to Lovable’s own managed Supabase, without explicit consent. Whatever the frontend export looks like, the backend and its schema are a separate migration project, one the AI designed and the builder may never have fully reviewed.

The tools that get this right, and what “right” costs

Bolt and v0 are the honest counter-examples, and worth naming as such. Bolt documents direct codebase download plus automatic GitHub sync producing a standard React/Vite codebase with no proprietary formats. v0’s own materials describe exports as clean, inspectable React and TypeScript code without proprietary layers or locking mechanisms. Both claims are closer to what “no lock-in” should mean: the thing that leaves the platform is the thing you’d actually want to keep building on.

But note what that honesty doesn’t remove. A clean export still hands you a codebase written by a model with a limited context window, still subject to the Day Two problem: it runs today, and whether it survives six months of real changes depends on whether anyone reviews what’s in it. Portable code is necessary for avoiding lock-in. It isn’t sufficient for avoiding the maintenance bill.

The question underneath the checkmark

Before trusting an export claim, three questions separate marketing from reality. First, what actually leaves: frontend only, or the backend and database with it. Second, who can read it without the tool’s help, since code nobody on the team can maintain is portable in name only. Third, what did builders who tried report, since a Reddit thread about a $480 exit fee tells you more than a pricing page checkmark.

For business apps, portals, internal tools, CRMs, there’s a structural way to sidestep the whole question: build somewhere the “export” isn’t code in the first place. On Softr, auth, permissions, and data structure are platform configuration, and the underlying data can live in sources you already control (Airtable, Google Sheets, or SQL) or be reached through Softr’s own database via API and MCP, so a builder isn’t waiting on a GitHub export to avoid depending on one vendor’s infrastructure. That’s a different trade than code ownership, not a replacement for it: you’re trading “I can export the code” for “the data was never trapped to begin with.” Which trade is right depends on whether the app needs a developer to own custom logic, the case for Cursor or Bolt, or needs to just work without one.