All posts
LightSprint is like Lovable on your existing codebase
Lovable can't connect to a repo you already have. LightSprint gives your team the same describe it, see it, ship it flow on your existing codebase, with live previews and pull request review.
Ben Ong
October 25, 2026
product-development
ai-agents
Your repo branching two ways on a light orange background: to Lovable, where the arrow breaks, and to LightSprint, then Preview, then Merge with a check mark
Can you use Lovable on an existing codebase? Not directly. Lovable can't connect to a GitHub repository you already have. Its Git sync always creates a new repository, and its import feature rebuilds your code as a new Lovable project. LightSprint gives your team Lovable-style building on the product you already run: it works inside your existing repo and sends each change through your normal pull request review.
Here's what Lovable supports today, what that means for a production codebase, and the options that work on your real repo.
Can Lovable connect to an existing GitHub repo?
No. Lovable's Git sync documentation lists this as a limitation: "Export only. You can't import an existing repository into Lovable. When you connect a project, Lovable always creates a new repository."
Git sync is built to move code out of Lovable, not into it. Per the same docs:
- Connecting a project creates a new repository on GitHub, GitLab, or Bitbucket.
- Each Lovable project links to one repository on one provider.
- Lovable syncs one branch at a time. Commits on other branches don't appear until they are merged into the synced branch.
- If you disconnect and reconnect, Lovable creates another new repository. You can't re-link the old one.
So if your app already lives in a repo with its own history, branches, and CI, Git sync can't attach to it.
What about Lovable's project import?
Lovable has a separate feature for bringing outside code in. According to Lovable's import documentation, you upload a ZIP of your code, and Lovable:
- Inspects the code, schema, and configuration.
- Rebuilds the app the way it builds new Lovable apps, on TanStack Start.
- Moves the database and users to Lovable's built-in backend.
The docs also note that import is rolling out gradually, ZIPs are capped at 250 MB, the code export doesn't include your database records or uploaded files, and imports consume credits based on project size and how much Lovable has to rewrite.
That's a migration, not an integration. You end up with a new app on Lovable's stack. Your original repo stays where it was, and the two start drifting apart from the first change.
Why this matters for a team with a production app
For a solo founder with a prototype, rebuilding inside Lovable can be fine. For a team with a live product, the existing repo is where the work actually happens:
- Customers use what's in that repo. A change made in a rebuilt copy doesn't reach them until someone ports it back by hand.
- The repo holds your conventions. Shared components, auth flows, design tokens, and naming patterns live there. A rebuild on a different framework doesn't carry them over as they are.
- Engineering review runs on that repo. Branch protection, CI, required reviewers, and merge rules are set up on the repository your team already ships from.
What most teams searching for "Lovable for an existing codebase" want is the Lovable experience (describe a change, see it working, ship it) applied to the app they already have. That needs a tool that starts from the existing repo.
Your options at a glance
| Option | Works on your existing repo? | Best for |
|---|---|---|
| Lovable Git sync | No. Creates a new repo | Backing up and deploying an app built in Lovable |
| Lovable project import | No. Rebuilds a copy on Lovable's stack | Moving an app onto Lovable for good |
| Developer coding agents (Claude Code, Codex) | Yes | Engineers who open their own pull requests |
| LightSprint | Yes | PMs, designers, ops, and engineers shipping PRs through your existing CI and reviews |
How to get Lovable-style building on your existing codebase
LightSprint is built for this case. Team members describe changes in plain language, and the agent works on your team's real repository, not a copy. Here's the flow:
- Connect your repo. LightSprint works from the GitHub repository your team already ships from.
- Describe the change. A PM, designer, ops lead, or engineer writes the outcome they want in plain language.
- Review a visual plan. LightSprint reads the codebase and turns the request into a shared plan the team can check before any code changes.
- Pick the agent. Run the change with Claude, Codex, a cloud agent, or your approved model gateway, including your own subscription.
- Click through a live preview. Each change runs in an isolated sandbox, so the team can test working behavior before anything merges.
- Hand off a pull request. The PR follows your existing CI, required reviews, and merge rules.
Roles keep engineering in charge. A Builder can propose changes and view previews but can't merge. An Approver, typically an engineer or lead, can review and merge. More detail is on our engineering page and security page.
When Lovable is still the right choice
If you're starting from nothing, Lovable is a strong option. It's quick to go from a prompt to a new hosted web app, and you don't need technical knowledge to do it.
Many teams use both. They explore a new idea in Lovable, then move to a shared workflow once the product lives in a real repository with real customers. We cover that handoff in Outgrowing Lovable and Replit, and the full side-by-side is in LightSprint vs Lovable.
FAQ
Can I connect Lovable to an existing GitHub repository?
No. Lovable's Git sync always creates a new repository when you connect a project, and it can't link to a repository that already exists.
Can Lovable import an existing project?
Yes, as a migration. Lovable's import feature takes a ZIP of your code and rebuilds it as a new Lovable project on TanStack Start, moving your database and users to Lovable's backend. It doesn't edit your original repository. The feature is rolling out gradually, so it may not appear in every account yet.
What's the best Lovable alternative for an existing codebase?
It depends on who's making the change. Engineers can use coding agents such as Claude Code or Codex in the repo. If PMs, designers, or ops need to ship changes with engineering approving the merge, LightSprint works on your existing repo with visual plans, live sandbox previews, and pull requests that go through your current reviews.
Can I use Lovable and LightSprint together?
Yes. They fit different stages. Lovable can help you explore a new concept, and LightSprint handles ongoing changes once the product lives in an established repository and team workflow.
Is LightSprint free to try?
Yes. LightSprint has a free plan. See pricing for what each plan includes.