# The eject button myth: exporting your AI-built app does not save it > The eject button is real but it will not save you: what exported AI-built code actually contains, and the drill that proves it. > By Dave · 2026-09-06 > Source: https://otf-kit.dev/blog/eject-button-myth-ai-built-apps Every AI app builder conversation eventually reaches the eject button: the promise that you can export your code and walk away any time. Here is the part nobody says out loud. The eject button is real — [Lovable documents two-way Git sync to a repository you own, plus one-click codebase download](https://docs.lovable.dev/integrations/git-sync-overview). The myth is that pressing it saves you. What lands in your repository is files, and files are not the same as a codebase your team can extend without a rewrite. [Lovable's own welcome docs](https://docs.lovable.dev/introduction/welcome.md) say each project produces a codebase that can be synced to GitHub or GitLab and integrated into existing engineering workflows. Take that claim seriously and test it literally: clone the synced repo on a machine that has never seen the builder, hand it to a developer who was not in the chat, and ask them to ship one real feature. The gap between "code exists" and "code survives contact with a roadmap" is the entire eject-button myth. ## Export is real, and that is not the problem Credit where it is due: the trap narrative is outdated. [Git sync keeps project code in your own GitHub or GitLab repository with automatic two-way sync](https://docs.lovable.dev/integrations/git-sync-overview) — edits in the builder commit to your repo, local commits sync back, and you can deploy outside the platform entirely. There is also a plain download option for a static copy. Lock-in at the file level is largely solved on the leading platforms. So stop auditing builders on whether export exists. Every serious one has it. The question that matters is what the export contains: conventions a stranger can follow, migrations a database can replay, tests a CI runner can execute, and configuration a coding agent can read. None of that comes free with a sync button. It comes from how the code was structured before you ever pressed it. ## What actually lands in your repository Run this audit on any synced or downloaded codebase before you need it in an emergency: ```text eject audit — run against a fresh clone [ ] README gets a stranger to a running app in under 30 minutes [ ] database changes replay from checked-in migrations, not memory [ ] test suite runs in CI and covers the money paths [ ] environment variables validated at boot with clear errors [ ] auth boundaries enforced server side, not in UI visibility [ ] one command deploys to an environment you control [ ] project context file tells a coding agent what not to touch ``` Most AI-generated codebases clear two or three of these. The README describes the builder, not the repo. The database is whatever schema the generator last wrote. Tests, if they exist, cover the demo path. Environment handling is a pasted key in a chat message. Each gap is a week of reconstruction work landing exactly when you can least afford it — during the migration that was supposed to take a weekend. This is not an argument against generating code with AI. It is an argument about where the value lives. The value was never the files. It is the decisions encoded around the files: the migration history, the acceptance checks, the boundaries. A builder that generates screens without generating those decisions gives you a beautiful starting point and an expensive eject. [Exporting an MVP to real code](/blog/export-lovable-mvp-to-real-code) walks through that conversion as a deliberate project, not a button press. ## The eject test to run this week Do not wait for dissatisfaction to discover your eject readiness. Schedule ninety minutes and simulate the exit: ```bash # eject drill: fresh machine, no builder access git clone eject-drill && cd eject-drill # 1. stranger test — follow only the README cat README.md # does it reach a running app? # 2. database test — replay from zero ls migrations/ 2>/dev/null || echo "NO MIGRATIONS — flag this" # can you build prod data from checked-in files alone? # 3. confidence test — run the suite npm test 2>&1 | tail -5 # what breaks, and does anyone know why? # 4. deploy test — ship somewhere you control # if this step needs the builder's dashboard, you rent, not own ``` Score it honestly. Every step that requires logging back into the builder is a dependency, not an asset. Every step a new hire cannot complete alone is undocumented ownership. The drill converts a vague fear of lock-in into a priced list of gaps, and a priced list can be scheduled, delegated, or accepted deliberately. ![a synced file dump that only builds inside its birth platform compared with an owned repo ](https://cdn.otf-kit.dev/blog/eject-button-myth-ai-built-apps/inline-1.png) ## Make the repo ejectable before you need it The fixes are unglamorous and mostly additive. Check in migrations from the first schema change. Add the project-context file your agent reads so generated code follows house rules instead of improvising. Require the README to reach a running app and test that claim on every major change. Put the money paths under test before the demo paths. Validate environment at boot so deploys fail with messages instead of midnight pages. Then give every agent change the same bar a human change clears. [An acceptance checklist that proves the change before merge](/blog/ai-agent-acceptance-checklist) — scoped diff, passing checks, reported evidence — is what keeps generated code reviewable after the hundredth prompt. Code that passes that bar is code you own regardless of which tool typed it. Code that never faced it is a liability with syntax highlighting. None of this requires abandoning the builder. Two-way sync means the owned repo and the builder can coexist: structure lives in the repo, speed lives in the chat. The teams that eject successfully are the ones that treated the repo as the product and the builder as the fastest way to edit it, from the first week. ## Own the code from day one The deeper question is rent versus own, and it is worth answering before the eject drill forces it. [Owning your code versus renting it](/blog/own-your-code-vs-rent) frames the math: rented speed now, priced against the reconstruction bill later. A codebase you can extend with any tool — Cursor today, whatever ships next year — is portable in the way that matters. A codebase that only builds inside one chat window is portable the way a screenshot is editable. The reusable starting point is concrete: the same component name, props, and look on web, mobile web, and native from one codebase, with project context and worked prompts checked in so a coding agent extends instead of regenerates. Paid full-stack kits bundle theming with auth, billing, and database access in code you own outright, which means the eject audit above passes on day one instead of becoming a migration project. Start from the verified [templates page](https://otf-kit.dev/templates), run the drill against the actual repo, and keep every gap priced and scheduled. The eject button myth dies the day you press it on purpose and everything works. Until that drill passes, you do not have an eject button. You have a download link and a hope. Close the gap while it is cheap — structure is a week now or a quarter later. ## Sources - [Lovable welcome and code ownership](https://docs.lovable.dev/introduction/welcome.md) - [Lovable Git sync overview](https://docs.lovable.dev/integrations/git-sync-overview) - [OTF templates](https://otf-kit.dev/templates)