Exporting Your Code From Lovable — What's in the Repo and What Isn't

You click Export. A zip lands on your desktop, and for a beat it feels like ownership — the thing you built is finally yours, portable, real. Then the question arrives: what is actually in here? The repo is a genuine starting point — and a genuinely incomplete one. This piece maps both sides of that line so you can hand the code to an engineer without guessing.

What actually lands in my repo when I hit Export?

The export gives you the React and TypeScript frontend source: component files, routing logic, utility functions, a package.json listing your dependencies, and any static assets the interface uses. That is the visible layer of your product — the part a user sees and clicks. You own it outright, and a competent engineer can read it on day one.

That list is more substantial than it sounds. Your UI logic, your component hierarchy, the shapes of the data your frontend expects — all of it is there, readable, modifiable, not locked inside Lovable's platform. For a solo founder who has been vibe coding toward a working screen, that export is proof the product exists as code. You can open the files in any editor. You can show them to an engineer and have a real conversation about what the app does.

The repo is also a complete record of your frontend decisions, even when those decisions were made by the AI and you did not fully notice them happening. Every library pulled in via package.json, every component pattern chosen — it is all present and auditable. That auditability is exactly what makes the next two sections worth reading carefully.

What does the export leave out — and why does that gap matter?

The export contains no environment variables, no secrets, no database connection strings, no deployment configuration, and no written record of the architectural choices Lovable made on your behalf. Those omissions are invisible during development — which is precisely what makes them dangerous when a real engineer opens the repo for the first time.

Walk through what is missing in concrete terms. Environment variables hold the keys your app uses to talk to external services: authentication providers, payment processors, email senders. Connection strings tell your app where its database lives and how to reach it. Deployment manifests describe how the app should be packaged and run on a server. None of these travel with the export. They exist inside Lovable's managed environment, and when the zip lands on your desktop, they stay behind.

The subtler absence is architectural documentation. Lovable made technology choices — which backend services to wire up, how data flows between components, which third-party APIs do which jobs. Those choices are embedded in the code but never explained anywhere in the repo. An engineer inheriting it must reverse-engineer intentions from implementation, which costs time and introduces risk.

Fraser Seymour put the problem plainly: "I'd like to see some indication of what architectural and technology choices these constructor apps make. I'd also like to see these tools able to accept guidance in these same domains. Prototypes and POCs are great but for an actual production codebase ignorance of the strategic elements is a nonstarter."

That is not a complaint about Lovable specifically — it is a structural fact about every vibe-coding platform today. The gap between a working prototype and a production codebase runs straight through the things the export does not include.

Why does my exported code run on my laptop but break everywhere else?

Your app runs inside Lovable because the platform quietly supplies everything the frontend needs: API keys, a hosted database connection, serverless function wiring. Export the code and those invisible dependencies do not come with it — so the app fails outside Lovable's environment until each dependency is explicitly re-declared and connected.

This is not a bug. It is the design of managed development environments. Lovable removes friction by handling runtime infrastructure for you, which is exactly what makes fast iteration possible. The cost of that convenience is that the seams between your code and the platform's infrastructure are never made explicit. When you export, you get the code. The infrastructure stays on Lovable's side of the wall.

The practical consequence: a developer who clones your repo and runs npm install will get errors that have nothing to do with the code quality. The app will fail to start, or start and immediately fail on any action that touches a backend service. The errors will look like bugs — missing environment variable, connection refused, undefined API response — but they are really missing infrastructure.

Sebastian Fluckiger, CTO and Partner at Virtido, hit this wall directly: "i ran into the usual back & forth after a certain code size anyways and abandoned it to move it into local dev with cursor."

The friction he describes is not unusual. As a codebase grows, the gap between what Lovable manages silently and what the code actually requires becomes harder to paper over inside the platform. Moving to local development is the natural next step — and making that move successfully requires knowing what the platform was supplying so you can supply it yourself.

What should I do with this repo before I hand it to an engineer?

Before any handover, do four things: write down what each major prompt session was trying to build, list every third-party service the app calls, collect all credentials currently stored in Lovable's UI, and run a dependency audit against package.json. An engineer who starts with that context does archaeology only on the hard parts — not on everything.

Each step exists for a specific reason.

Document the intent behind the sessions. Your AI-generated MVP was built through prompts, and the prompts encode the product logic — what a feature was supposed to do, what edge case you were trying to handle. That context does not live in the code. Write it down before you hand the repo over, even if the notes are rough.

List every external service. Authentication, database, file storage, email, payments — name them all. The engineer needs to know what accounts to provision, what API keys to request, and what the data flow looks like before touching a line of code.

Collect credentials from Lovable's UI. Any keys or tokens you configured inside the platform need to be retrieved now. Once you move off the platform, they may not be accessible in the same place.

Run a dependency audit. Open package.json and review what is installed. Some packages may be outdated, some may carry known vulnerabilities, and some may be present from earlier experiments that are no longer relevant. This is the beginning of addressing your tech debt — the accumulated shortcuts that made the prototype fast and will make the production build slower to harden.

Nate Pinches describes a handoff workflow that captures the spirit of this preparation: "My best path so far has been starting in a front end coder that loads libraries, like V0, getting the front end built then taking it to Cursor and building in middleware and connecting all the buttons and stuff for the backend." The transition he describes — from fast frontend tooling to a more deliberate backend build — works because the handoff point is clear. The frontend is finished and documented before the harder work begins.

Patrick Ndifon, EMBA, Founder of Hack51 Africa, frames the underlying discipline: "Plan, plan, plan. From prd to develop guide. Plan. Break features into detailed tasks. Planning keeps you guided and keeps the AI in line. It helps you think about the tooling, frameworks, approaches before hand, so you know what will work together and not."

That discipline — knowing your tooling and your architecture before the engineer arrives — is what separates a handover that costs two days from one that costs two months.

The repo is a starting point, not a finished handoff

The Lovable export gives you real, readable, modifiable frontend source code. It does not give you environment configuration, deployment infrastructure, or any written record of the architectural decisions made on your behalf. Those gaps are not failures — they are the expected shape of a managed development environment at the moment it hands you the wheel.

The founders who move fastest from prototype to production are the ones who treat the export as an audit trigger, not a finish line. Name what you have. Name what is missing. Write down what the app is supposed to do. Then hand it to an engineer who can ask the right questions — because you have already answered the obvious ones.

What now? Open your exported repo, create a plain text file called HANDOVER.md, and fill in three sections before the end of the day: services the app calls, credentials that need to be transferred, and one paragraph per major feature describing what it is supposed to do. That file is the difference between a smooth onboarding and a slow, expensive archaeology project.