platform transition · 5 min read

AI App Builders for an Existing App: What "Import" Actually Means (2026)

Seven AI app builders, sorted by whether they take the repository you already have, what they write into it, what the preview can see and how changes come back.

Updated 2026-09-07

A grid of seven AI app builders scored on four questions about an existing repository, with two builders unable to take the repository at all

Every "best AI app builder" page assumes you have nothing yet. You have an app. It has users, a database with real rows in it, and a repository with history. The feature lists don't help, because the thing that matters never makes the list. What happens to that repository once the builder gets hold of it?

"Import from GitHub" appears on most of these products now, and it means something different on each one. This is the matrix we wish had existed when we started answering these questions one at a time.

Four questions that matter more than the feature list

  1. Does it take your repository, or make its own? Some builders can only work in a repository they created. Your history, issues, branch rules and deploy hooks all stay pointed at the one they can't see.
  2. What does it write into your repository? Runtime files that make the builder's Run button work end up in your git history and, with two-way sync, in production.
  3. What can the preview see? A preview that can't reach your database or your payment provider shows you the layout, not the behaviour.
  4. How do changes come back? A pull request your team reviews, or a push to the default branch.

The matrix

BuilderTakes your repo?Writes into itPreview can see real services?Changes come back as
LovableNo. Connecting creates a new repon/an/an/a
Base44No. Creates a new repo, permanently linkedn/an/an/a
BoltYes, personal accounts onlyA whole-project commit on each pushBrowser runtime, Node only, keys pasted inPush to the default branch
ReplitYes.replit and replit.nixYes, every secret re-entered by handTwo-way sync
Firebase StudioYes, GitHub, GitLab or Bitbucket.idx/dev.nixYes, once you configure the environmentOrdinary git from the workspace
v0Yes, private repos and monoreposNothing, but needs a Vercel project alongsideDevelopment variables onlyPull request against your base branch
RefinarYes, repositories you selectNothingYes, over HTTPS, read-only until approvedDraft pull request on a session branch

Lovable and Base44 can't take it at all

Lovable's git sync docs are plain about it. Connecting a project always creates a new repository. Base44's GitHub integration works the same way, and adds terms of its own. The sync is permanent and only the main branch is supported. Your data entities never make it into the repository at all. Both are good at starting an app. Neither can adopt one.

The three that take it and leave a file behind

Bolt imports a repository and runs it in WebContainers, a Node runtime inside your browser tab. That's quick to try and rules out Python, Go, PHP and anything needing a native binary before you start. Organisation accounts aren't supported, and each push lands as a whole-project commit on your default branch, so put branch protection on before you connect it.

Replit imports into a real cloud environment with Python and Go alongside Node. Importing isn't read-only, though. It writes .replit and replit.nix into the project so the Run button works, and two-way sync carries them back. Secrets are re-entered by hand, one at a time. The Replit post has the detail.

Firebase Studio is Google's entry and rarely turns up on these lists. It imports from GitHub, GitLab or Bitbucket, and its environment is defined by .idx/dev.nix in your repository. For a stack it recognises that's generated for you. For anything else, the docs say the files are uploaded and the initial setup is yours to do by hand.

The two that take it and leave nothing

v0 has imported existing repositories since January 2026 and works on them directly, opening pull requests against the base branch you choose. The cost is a Vercel project. You don't get previews or deployments without one attached, and the preview sees only Development variables, so anything behind a live key needs test-mode credentials seeded by you. Read the v0 post if production runs somewhere other than Vercel.

Refinar is a GitHub App you install on the repositories you choose. It checks the app out into a sandbox, gets it running there, and hands the result back as a draft pull request on its own branch, so your repository picks up a branch and nothing else. No runtime files, no second deployment target. The preview talks to the same database and payment provider the app already uses, over HTTPS, and it can only read from them until a person allows a write. Anything that touches sign-in or payments, or reaches into customer data, waits for a developer to approve it, yours or ours. We make it. Treat this row the way you'd treat any vendor's row, and try it on a fork before you believe it.

Which one

  • Starting from nothing: Lovable or Base44, and this page isn't for you.
  • A Node app, a personal GitHub account, quick experiments: Bolt.
  • A cloud workspace with real runtime range and you'll accept the config files: Replit or Firebase Studio.
  • A Next.js app that already deploys on Vercel: v0.
  • An app on GitHub that a non-developer needs to change without touching production: Refinar.

Whichever row you pick, know which commit is live and which services live outside the repository first. The production readiness checklist covers that, and the Lovable alternatives post ranks these against the developer tools this table leaves out.