Check what you can export and delete from a website builder
A practical way to test whether your pages, assets, prompts, and account data can leave with you.
6 min read
In this note
Which AI website builders let you export the code
Lovable, Bolt, v0, Base44, Webflow and Framer all let you take the code or the built site with you, and Hostinger's AI Builder gives you a project ZIP. Wix does not: its help centre says the site has to stay on Wix's servers. Squarespace exports content only. The plan you need and the parts left behind differ, so read the row for the tool you are weighing. Each row comes from the vendor's own help page or pricing page, listed under Sources.
| Tool | What you can take | Which plan | What stays behind |
|---|---|---|---|
| Lovable | The full code, synced to GitHub, GitLab or Bitbucket. Code download as well. | Git sync on every plan, code download from Pro | Hosting at lovable.app, unless you deploy the code somewhere else |
| Bolt | The project code, synced both ways with a GitHub repository | Its GitHub help page names no plan | Nothing named on that page. You can publish from GitHub with Bolt hosting, Netlify or another host. |
| v0 | Next.js code. Export, plus two-way sync with GitHub. | Its GitHub documentation names no plan | Nothing named. v0 deploys to Vercel and can deploy elsewhere. |
| Base44 | A copy of the app's code in a new GitHub repository | Builder plan or higher | Syncing. Each export is a snapshot, and you push again after every change. |
| Webflow | The site's HTML, CSS and JavaScript | Code export comes with the Core workspace plan, $19 a month billed yearly, on top of the site plan | Forms stop working. CMS content exports one collection at a time. |
| Framer | The published site as HTML, CSS, JavaScript and static assets. CMS content as CSV or JSON through plugins. | Every published site | Editing on the canvas and in the CMS. The download is a static copy. |
| Hostinger AI Builder | In agentic mode, a React and Vite project as a ZIP | Its export help page names no plan | Backend data stays in AI Builder. You convert the project to static files before it runs on shared hosting. |
| Squarespace | One WordPress .xml file with layout pages, one blog, and text and image blocks | An active subscription. An expired site is reactivated first. | Store pages, product and video blocks, style settings and custom CSS |
| Wix | No code or site export | None | The whole site. Wix says it has to be hosted on Wix's servers. |
| iter0 | The page as HTML, a ZIP for a multi-page site, or a pull request in your GitHub repository | After you sign in | Nothing for a single page. A page iter0 builds has no sign-in or database behind it. |
Export a disposable project first
Create a small test site with one page, one uploaded image, a custom button link, and a form. Then use the builder's export control. Open the downloaded files outside the product. Can you find the page copy, image, styles, links, and form configuration? Can another developer change the text and preview the result without your paid account?
A screenshot or a PDF keeps the appearance but not an editable site. Source files without images or routing instructions leave you stuck too. Record what is missing. A product can offer a legitimate export while still tying some functions, such as hosting or form submissions, to its own service. The point is to know which parts you can move.
Check saved prompts and memory separately
The generated page is not the whole project. Many AI builders also store your prompts, uploaded source pages, design references, chat history and a saved description of your business. Look for a way to export or remove each category. Delete a harmless test note, open a new session, and see whether the assistant still uses it. If the interface only hides the note, ask how long the underlying record remains and whether it can enter later sessions.
Do not put customer records or private financial information into a test. A disposable example lets you check controls without creating a second privacy problem.
Run a deletion test before you rely on the promise
Delete that same disposable project. Check whether its published URL stops working, whether its uploaded image remains reachable at a known address, and whether the project still appears in search or account history. Read the product's retention terms for backups, billing records, and support logs. Deleting a project in the interface does not prove every backup was instantly erased.
For personal data, the UK's Information Commissioner's Office explains that a valid erasure request can be met in live systems while backup copies persist until their overwrite schedule. It also explains that data portability concerns usable, structured formats. Those legal rights have conditions and do not automatically cover every company design file; this checklist is a buyer's practical test, not legal advice.
Keep an exit note for the real site
Write down the domain registrar, hosting provider, repository or export location, image originals, form destination, analytics account, and people with access. If you change builders later, this note tells you which parts move with the files and which services need a separate replacement. Review it after the first live launch, because the form and domain often change later.
A useful ownership claim is one you can exercise. If you cannot get a complete enough export, remove a test memory, or understand what deletion leaves behind, include that cost when comparing builders.
Put the brief into practice
A launch page should make the buyer, promise, proof, and next action obvious. iter0 uses this same standard when it turns a brief or reference site into a builder-ready page.
Start your launch build