The short verdict
- Exporting gives you a real codebase, usually React with Tailwind. That is genuinely useful.
- It does not give you a CMS, an editor for non-developers, or anyone to maintain it.
- For an app, export is a good path. For a marketing site, it often moves the problem rather than solving it.
01What each tool gives you
Details change often, so check each tool’s current docs. Broadly, at the time of writing:
| Tool | How you get the code | Typical stack |
|---|---|---|
| Lovable | Two-way sync to a GitHub repository | React, Vite, Tailwind, shadcn/ui, often Supabase |
| Bolt | Download as a zip, or push to GitHub | Varies by prompt, often React and Vite |
| v0 | Copy components, install via CLI, or deploy a project | Next.js, Tailwind, shadcn/ui |
02What is in the export
A working front-end project. Components for each section, a styling setup, routing between pages, and any connections to a backend like Supabase that were set up during prompting. A developer can open it, run it and change it like any other React project.
The code quality is usually reasonable at small sizes and gets messier the more the project was prompted. Long sessions leave dead components, repeated styles and logic that only made sense three prompts ago.
03What is not in the export
- An editor for your team. Changing a headline means editing a code file and redeploying.
- A CMS. Blog posts and case studies are hard-coded, unless someone wires up a headless CMS.
- Hosting. You need somewhere to deploy it, like Vercel or Netlify, and someone to manage the domain and builds.
- SEO setup. Per-page metadata and server rendering are often missing, as covered in our rendering post.
- Maintenance. Dependencies need updating. Security patches need applying. That is ongoing developer time.
“Exporting the code means owning the code. That includes the parts nobody enjoys.”
04When exporting makes sense
If what you built is an app, with accounts, data and logic, exporting is often the right move. A developer can take it from there and grow it like any other product codebase. If you already have developers, they may be happy to maintain a marketing site as part of the product repo.
05When it does not
If what you built is a marketing site and the people who need to edit it are not developers, exporting swaps one bottleneck for another. Instead of prompting the tool, you are asking a developer. For that case, rebuilding the site on a visual platform is usually cheaper over a year than maintaining exported code.
The export is still useful there. It is a precise record of the content, the pages and the design, which makes a rebuild faster and more accurate.
06If you do export
- Put it in your own GitHub account, not a personal one that might leave with someone.
- Get a developer to review it once before building on it. Clearing dead code early is cheap.
- Pin and update dependencies on a schedule.
- Move secrets out of the code. Check no API keys were committed during prompting.
07Questions people ask
Can I keep editing in the builder after exporting?
With Lovable’s GitHub sync, yes, both ways. With a one-off download, changes made in the code will not flow back into the builder.
Can you import exported code into Webflow?
Not directly. Webflow builds pages visually. We rebuild the design and content in Webflow, using the exported site as the reference.
Is exported code mine to use however I like?
Generally, yes, but read your tool’s terms. Also check the licences of any libraries and images included.
Should I export or rebuild?
Send us the link and tell us who edits the site. That usually decides it.
