How to download a Lovable project and prep the code for agents

An exported Lovable or Bolt MVP gives you source files, but source files alone do not make a codebase easy to change. The next job is to get a reproducible local checkout, identify the app’s real boundaries, and leave enough project context for the next developer or coding agent to make a safe change.

This guide keeps that goal intact while adding the current Lovable download and GitHub paths. The key handoff is from a builder project to a repository your team can inspect, test, and keep extending.

Download a Lovable project, then move it into GitCopy Anchor Link

Lovable documents two ways to copy a project’s code. For a one-time download, open Project settings → Git → Download codebase, or open the Code editor and choose Download codebase at the bottom of the file tree. Lovable lists this download option for paid plans. The archive is a local copy; it does not connect an existing GitHub repository back to the Lovable editor.

For ongoing work, connect the Lovable project to GitHub. Authorize the intended GitHub account or organization through a workspace connection, then connect the project from its GitHub settings. Lovable creates a new GitHub repository for that project, private by default, and starts two-way sync. Confirm the owner before connecting client or company work.

When the connection is active, copy the HTTPS, SSH, or GitHub CLI clone URL shown in the project’s GitHub settings. Clone the actual repository URL:

git clone https://github.com/your-account/your-lovable-project.git
cd your-lovable-project
git status --short --branch

Replace the example URL with the one in your project settings. Lovable syncs one active branch at a time. Check the active branch and sync status before local edits; changes on another branch need to be merged or selected in Lovable before the editor sees them.

A clone is only the first check. Inspect the lockfile and package scripts, use the matching package manager, then run the build or tests the repository actually defines. For example, run npm ci only when package-lock.json is present, and npm run build only when package.json includes a build script. Do not assume that code download also transfers production environment values, hosted data, auth settings, or service credentials.

Before pushing changes, inspect for accidentally committed secrets and test with non-production configuration. Keep a backup of the source repository and make the first change small enough to review or revert.

Treat the export as a starting pointCopy Anchor Link

A working preview answers whether the MVP can render. It does not tell you whether the project can be maintained safely. Start by running the app from a clean checkout and writing down what works, what needs a hosted service, and what is only sample data. Keep that baseline so later cleanup does not silently change the product.

The exported tree may contain duplicated page logic, inconsistent naming, scattered styles, and assumptions that only exist in the original builder conversation. Check the actual files before reorganizing them. Some projects are already well-structured; change only the parts that make the next feature harder to locate, test, or review.

1. Name folders for product responsibilityCopy Anchor Link

Group files by the feature or domain they implement, not only by their visual position. A folder called components/ may be useful, but a dozen files called Hero, Section2, and Section3 do not explain the behavior they own.

A small app might start with:

src/
  features/
    signup/
      SignupForm.tsx
      validation.ts
      api.ts
    billing/
      PlanCard.tsx
      checkout.ts
  shared/
    Button.tsx
    TextField.tsx

Do not move every file in one large pass. Pick one flow, update its imports, run the relevant checks, then continue. That keeps a broken path easy to trace.

2. Separate rendering from business behaviorCopy Anchor Link

A page component should not have to explain every network call, validation rule, and state transition at once. Move stable behavior into named functions or feature modules, then have the page compose them.

For example, a signup flow can separate a form’s rendering from validation and submission:

export function validateSignup(email: string) {
  if (!email.includes("@")) return "Enter a valid email address";
  return null;
}

The example is intentionally small. In the real app, keep the server as the authority for permissions, account creation, payments, and other protected operations. A client-side check improves feedback; it is not an access-control boundary.

Add tests around behavior that could cost a user data or money: validation, permission checks, payment state, and failure responses. A clean-looking component tree is less useful than a focused check that catches a broken write.

3. Put repeated visual choices in one placeCopy Anchor Link

An MVP often accumulates slightly different colors, spacing, and button states as prompts add screens. Record the choices the product actually uses in shared tokens or components, then replace repeated one-off values as you touch those files.

Start with a short list: color roles, type scale, spacing steps, radii, and interactive states. Use names that describe a purpose, such as surfaceRaised or textMuted, instead of names tied to a single screen. A new theme or redesign is easier when the same intent is expressed once.

Do not build a design system the product does not need. The goal is to make repeated decisions consistent and easy to change, not to add an abstraction for every element.

4. Give the next agent useful repository instructionsCopy Anchor Link

The builder chat is not a durable project guide. Add a short README with the verified setup, the commands that work, where key features live, and any external services needed for local development. If your coding tool reads repository instructions, add its supported instruction file with the same facts.

Prefer instructions that point to evidence:

## Local checks
- Install dependencies using the package manager that matches the lockfile.
- Run the app with the command in package.json.
- Signup validation lives in src/features/signup/validation.ts.
- Do not use production credentials for local development.

Avoid copying a generic list of rules that conflicts with the actual code. Ask an agent to inspect the project and cite the files it used before it edits a sensitive flow. Review the diff and run the check that covers the changed behavior.

5. Keep assets discoverableCopy Anchor Link

Move assets into folders that explain their use, but preserve paths until references are updated. For example, a feature-specific illustration can live beside the feature that uses it, while a shared logo remains in a common asset folder. Search for references before deleting duplicates; a file that looks unused may be loaded by a route or stylesheet.

Use descriptive names and keep source files when the team needs to edit them. If the export includes generated or temporary assets, separate those from product assets instead of deleting them in bulk.

6. Keep one source of truth across surfacesCopy Anchor Link

If the MVP is web-only, avoid inventing a mobile architecture before there is a mobile requirement. If you do need a second surface, identify which behavior and data model should stay shared and which UI must be platform-specific. Copying screens without an ownership plan creates two versions that drift.

Record the boundary in the repo and test the critical user flow on each supported surface. The same requirement should have one source of truth for business rules even when the presentation differs.

7. Turn repeated agent work into a reviewable loopCopy Anchor Link

Once the project has a local setup and clear boundaries, give agents narrow tasks with acceptance checks. Ask for one feature or refactor at a time. Have the agent list the files it plans to change, preserve unrelated behavior, and report the checks it ran.

For a change that touches data or auth, include the failure case in the task. For a visual change, name the screen and states to preserve. Keep the change in a branch or a small commit so a reviewer can compare the result with the baseline.

What the handoff gives youCopy Anchor Link

The goal is not to make an export look more formal. It is to make the next change predictable: a clean checkout can install, the relevant flow has a named home, project decisions are written down, and the test result matches the changed behavior. That is what lets a coding agent or a new teammate continue without reconstructing the original chat.

For a repository-first starting point rather than a builder export, see OTF Kit at https://otf-kit.dev. Its templates are a separate starting point; an export still needs the checks and project decisions described here.

SourcesCopy Anchor Link

• Sync your Lovable project with GitHub — Lovable documentation — current download locations, paid-plan note, repository creation, clone URLs, and active-branch sync behavior.
• Turn a Lovable MVP export into an AI-friendly codebase — related guide on the supported GitHub direction and import limitation.