DEV Community: Mufasa

Framer doesn't export HTML. When that matters, and when it doesn't

Mufasa — Thu, 01 Oct 2026 07:39:31 +0000

A client asks for "the site files" so their IT team can host it next to everything else. You built it in Framer. What do you send them?

Nothing, it turns out. Framer's help center says it in one line: "Framer does not offer HTML export for self-hosting."
(source)

Its performance features run on Framer's own hosting, so the site lives there. Scraper tools exist, but they aren't Framer's, and a scraped copy can lose whatever the hosting was doing for it.

Disclosure up front: we make Swebsy, a visual builder that does export plain HTML. So weigh what follows. Every Framer fact links to Framer's own pages, checked 30 September 2026.

When it doesn't matter

For a lot of sites, managed hosting is exactly what you want. Framer is a very good design tool that happens to publish, and on its plans you get:

a CMS (2 collections on Basic at $10/month billed yearly, 10 on Pro at $30)
staging and redirects on Pro
team editing, at $20/month per extra editor
a built-in AI agent on monthly credits

(pricing)

Framer's editor and built-in agent, from the demo on framer.com.

If your site needs a CMS, several editors, or heavy motion, and nobody will ever ask for the files, Framer is a strong pick, and losing HTML export costs you nothing.

When it does

The site has to live on your infrastructure. Compliance, a company CDN, an internal network.
A client owns the deliverable. "Here's the ZIP" is a cleaner handoff than "here's a seat on my account".
You want to be able to leave. If pricing or limits change, moving off Framer means a rebuild, not a redeploy.
You want free hosting for a small site. GitHub Pages and Cloudflare Pages host static files for $0 on your own domain. Framer's custom domain starts at the $10/month Basic plan.

What exporting looks like in Swebsy

Swebsy exports a ZIP of plain HTML, CSS and assets on every plan, including free, with no account. It's one click from the Deploy menu.

Deploy → Export code downloads the site as a ZIP.

What's inside is what any static host expects:

├── index.html
├── about.html                  # one file per page
├── css/
│   └── styles.<hash>.css       # every style, in one file
├── js/
│   └── swebsy-components.<hash>.js  # only when a page needs it
├── assets/                     # your images
├── fonts/                      # self-hosted fonts
├── sitemap.xml
└── robots.txt

You also get an editable project file you can import later. On the free plan the pages carry a small "Made with Swebsy" badge; a paid plan removes it.

The trade-offs, plainly: no CMS, no team seats yet, and no Framer importer. Moving means rebuilding the pages, usually from a template.

It also has an MCP bridge, so Claude Code or Cursor can edit a project open in the editor. You bring your own agent and pay its provider; nothing is billed per token on our side. Framer has its own take on this: external agents, currently in beta.

The short version

Pick by where the site has to live. If Framer's hosting is fine forever, Framer's design tools are hard to beat. If the files have to leave with you, check that before you build, not after.

The full side-by-side, with prices for a few common jobs: Swebsy vs Framer.

Static or dynamic? What exporting a visual-builder site really gets you

Mufasa — Thu, 01 Oct 2026 07:39:03 +0000

"Can I export it?" gets a yes from more visual builders every year. The better question is: export it as what?

There are two answers. A static export is a folder of files any web server can hand out. A dynamic export is an application that runs code on every request. They differ in where you can host them, what they cost to run, and what still works once they've left the builder.

Webstudio is a useful example because it offers both. Disclosure up front: we make Swebsy, a visual builder that only does the static kind. So weigh what follows. Every Webstudio fact links to Webstudio's own docs, checked 30 September 2026.

Webstudio's builder, from webstudio.is/visual-editor.

Dynamic: an app you run

Webstudio's JavaScript application export builds a Remix app. It's what Webstudio Cloud itself runs, and it supports CMS integrations, webhook forms, image optimization and redirects.

The cost is hosting. Webstudio's docs say it "requires hosting that works with apps": a platform like Vercel or Netlify, or your own server. Someone has to keep that app updated and running.

Pick this when pages come from a CMS at request time, or the site needs server-side behaviour.

Static: a folder of files

A static export is HTML, CSS, JavaScript and images. GitHub Pages, Cloudflare Pages, an S3 bucket or a company web server can all serve it, many of them for free, and there's nothing to patch.

What you give up depends on the builder. Webstudio's docs list what its static export does not support:

dynamic pages
redirects and status codes
client-side navigation
webhook forms
image optimization
robots.txt and sitemap.xml

That's not a flaw in Webstudio. Several of those need a server by definition. But the last three are things a static build can do ahead of time, and it's worth checking which ones your builder does.

A checklist for any static export

Before you trust an export, unzip it and look for:

A file per page, with each page's title, description and canonical URL in its <head>.
sitemap.xml and robots.txt, or a plan to write them.
A 404.html, so missing URLs don't fall back to the homepage.
Optimized images. Are the photos still multi-megabyte PNGs?
Forms. Where does a submission go? Send a real test from the live site.
Redirects. If old URLs need to move, you'll set them on the host.

What Swebsy's static export does

Swebsy only exports static sites, so it does the static work at export time. Deploy → Export code gives you one HTML file per page, a single stylesheet, your assets and fonts, a sitemap.xml, a robots.txt and a 404.html.

├── index.html
├── about.html                  # one file per page
├── 404.html
├── css/
│   └── styles.<hash>.css       # every style, in one file
├── assets/                     # your images
├── fonts/                      # self-hosted fonts
├── sitemap.xml
└── robots.txt

Image optimization is a setting: turn it on and photos are re-encoded to WebP or AVIF during the export, with every link updated to match.

Settings → Performance & Security. Balanced re-encodes photos to WebP on every export.

What it doesn't do: dynamic pages, a CMS, or redirects (set those on your host). Forms collect on Swebsy Hosting, or post to a form service you choose anywhere else. The export is free on every plan, with no account; on the free plan the pages carry a small "Made with Swebsy" badge.

The short version

If your pages exist before anyone visits them, a static export is simpler, cheaper and easier to keep running. If pages are built from a CMS per request, you need the dynamic kind, and a host that runs apps.

The full side-by-side, with prices: Swebsy vs Webstudio.

Webflow's code export: what's in the ZIP, and what stays behind

Mufasa — Thu, 01 Oct 2026 07:38:37 +0000

Unlike most hosted builders, Webflow will give you your code. Open the main menu, choose Code export (or press Shift + E), click Prepare ZIP, and you get the HTML, CSS, JavaScript and images. (source)

That's more than Framer offers. But "you can export" and "you can leave" are different claims, and the gap between them is worth knowing before you build.

Disclosure up front: we make Swebsy, a visual builder that also exports plain HTML. So weigh what follows. Every Webflow fact links to Webflow's own pages, checked 30 September 2026.

Who can export

Export sits on Workspace plans, not Site plans. Webflow's help center is explicit: "Site plans do not include the ability to export your site's code."

Site plans pay for hosting: Basic $15/month, Premium $25/month (with the CMS).
Workspace plans pay for your team's tools: Core, from $19/month, is the first one with code export.

All billed yearly (pricing). So a hosted site you can also export runs $408 a year on Basic plus Core.

Webflow's Site plans. Code export is on the separate Workspace plans, from $19/month.

What's in the ZIP

Every page as an .html file, a css/ folder (your styles plus webflow.css and normalize.css), a js/ folder, and an images/ folder. No attribution is required, and the exported site keeps working without a Webflow plan.

The JavaScript matters: navbars, sliders, tabs, interactions and forms all depend on it. Webflow warns that if you delete those files, "your page might look correct, but it won't work as expected."

What stays behind

This is the part to read twice. From the same help page, these don't come with the export:

CMS content. Collection lists show their empty state, and Collection pages lose anything bound to Collection fields.
Form processing, including file uploads and reCAPTCHA.
Site search.
Password protection. Protected pages become public.
User accounts and ecommerce.
Localized content. Only the primary locale is exported.
Code components.

You can download CMS Collections as CSV, but that's a backup of the data, not the pages that showed it.

So the export is a faithful copy of a static site. A CMS-driven site comes out as templates with holes in them.

When that's fine

The site was static to begin with. A marketing site with no collections exports cleanly. Add a form service and you're done.
You want a backup. Webflow lists "back up your code" as a use case, and it's a good one.
You're handing static pages to a client who hosts them.

When it isn't

The blog runs on the CMS. Moving off Webflow means a new content system, not a redeploy.
You rely on protected pages or site search. Those need Webflow's hosting.
You want to edit the export and keep designing in Webflow. Webflow notes that manual changes "may break some Webflow components", and the next export starts from the Webflow project, not your edited files.

What exporting looks like in Swebsy

Swebsy has no CMS, so its exports are static by design, and the export is free on every plan, with no account. Deploy → Export code downloads a ZIP of plain HTML, CSS and assets, along with a sitemap.xml and a robots.txt.

View → View Code shows the exported HTML for the current page before you download anything.

Forms are the same trade-off as Webflow's: Collect with Swebsy needs Swebsy Hosting, and anywhere else you point the form at a service you trust. On the free plan the pages carry a small "Made with Swebsy" badge; a paid plan removes it.

The trade-offs, plainly: no CMS, no team seats yet, and no Webflow importer. Moving means rebuilding the pages, usually from a template.

The short version

If your Webflow site has no collections, its export is real and useful, as long as you're on a Workspace plan. If the CMS carries the site, the export is a backup, not an exit.

The full side-by-side, with prices for a few common jobs: Swebsy vs Webflow.

One page or several? When a Carrd site outgrows its sections

Mufasa — Thu, 01 Oct 2026 07:38:18 +0000

Carrd is one of the best deals on the web. $19 a year gets you a custom domain, forms and 10 sites (pricing). For a profile, a link-in-bio or a launch page, it's hard to argue with.

Every Carrd site is one page. Its sections let you "simulate the effect of having multiple pages on a one-page site": visitors click a link and the view changes, but it's still one page underneath.

That's often fine. This piece is about spotting when it stops being fine.

Disclosure up front: we make Swebsy, a visual builder for multi-page static sites. So weigh what follows. Every Carrd fact links to Carrd's own pages, checked 30 September 2026.

When one page is exactly right

Carrd's starting points at carrd.com/build. Every template is one page, split into sections.

A personal profile: a bio, a few links, a contact button.
A launch or waitlist page with one form.
An event page that will be gone in a month.

If your site fits one scroll and one message, one page is a feature. Fewer controls, less to maintain, and Carrd's editor gets you live in an evening.

Signs you need real pages

You want to share a link to one thing. "Here's my pricing" should be /pricing, with its own title and preview card when it's pasted into a chat.
Each part has its own audience. Services for clients, case studies for referrers, an about page for the curious.
The page has become a long scroll you're afraid to touch, because moving one section shifts everything else.
You want a page per service or location so each one can answer a specific search.

Don't move for SEO myths, though. One page versus several won't rank you by itself. Useful content and working links matter far more.

What changes with real pages

Each page becomes its own file with its own address, title and description. In Swebsy, every page exports as its own HTML file and gets its own entry in the sitemap.xml.

Swebsy's Clarity template comes with separate Home, About, Insights and Method pages.

Shared parts stay shared. A navbar or footer made into a symbol updates on every page at once, so five pages aren't five times the upkeep.

What it costs you

Honestly, some things get worse:

Price, if you want hosting. Carrd's $19/year is cheaper than our hosted plans ($69/year). Swebsy is cheaper only if you host the files yourself on GitHub Pages or Cloudflare Pages, which is free.
Simplicity. Swebsy has a full design panel, layers and theme tokens. There's more to learn.
Forms. Carrd's forms plug straight into mailing tools like Mailchimp or Kit. In Swebsy, forms collect on Swebsy Hosting, or post to a form service you choose.

And one thing gets better: the files. Downloading a Carrd site needs Pro Plus ($49/year), forms stop working in the download, and "the downloaded version of a site cannot be uploaded back to the Carrd platform" (source). Swebsy's export is free, and its separate project backup can be imported again to keep editing.

The short version

If your Carrd site does its job and updating it feels easy, stay. Move when you can name the page you're missing, and not before.

The full side-by-side, with prices for a few common jobs: Swebsy vs Carrd.

Drive a visual site builder with your own Claude/Cursor via MCP

Mufasa — Mon, 20 Jul 2026 19:40:55 +0000

I've been building Swebsy, a visual website builder, and last week we shipped something I haven't seen any other builder do. I want to talk about it because I think it's a genuinely different way to think about "AI in a builder" — and honestly I'm not sure why nobody else is doing it.

The problem with "AI website builders"

Look at the current crop. Every one of them bolts an AI chat panel onto their editor and bills you for it. Some markup on top of the raw API tokens, some seat price, some credit system that runs out right when you're in flow. The pitch is always "describe your site and watch it build itself."

Two things about that always bugged me:

You're paying twice. If you already pay $20/mo for Claude, or you have a Cursor seat, or Copilot through your job — you're already paying for a coding agent. Then the builder charges you again to use their wrapper around a model you're already subscribed to.
You don't get to use your agent. You get their agent. Their prompt, their model choice, their context window, their guardrails. If you've spent months tuning how you work with Claude Code or Cursor, none of that comes with you.

What we did instead

We shipped an MCP server (@swebsy/mcp). If you don't know MCP — it's the Model Context Protocol, the open standard for connecting coding agents to tools. Claude Code, Codex, Cursor, Windsurf, Copilot all speak it.

So instead of building our own AI panel and metering it, we made Swebsy a tool your existing agent can drive.

claude mcp add swebsy -- npx -y @swebsy/mcp

That's the whole setup. Now Claude Code (or whatever you use) can read your live canvas, add sections, edit content, take screenshots to check its own work — the same editor you're clicking around in, driven by the agent you already have open.

The cost to us of your AI usage: zero. The cost to you: zero extra. You use the plan you're already paying for.

Why this feels obviously right (and I don't get why it's rare)

No per-token billing. We're not in the loop on model costs at all. Your agent, your subscription, your quota.
It runs on your machine. The bridge is a local 127.0.0.1 WebSocket. Your agent talks to your open editor tab. We're not proxying prompts through our servers, secrets stay redacted, nothing gets shipped off to us to bill against.
You keep your setup. Your agent, your model, your custom instructions, your muscle memory. We didn't ask you to relearn a new chat box.
We dogfooded it. The section on our landing page announcing this feature? An agent built it, live, through the MCP. It's turtles all the way down.

The strategic bit, if you're into that: this isn't us claiming to be an "AI website builder." Our core promise is still boring and honest — build visually, export real files, publish where you want. The agent story is a reason to believe, not a new category we're pretending to own. The people it lands with are technical founders who already live in a coding agent all day. We just met them where they already were instead of building a worse version of the tool they already love.

The counterintuitive part

Every instinct in SaaS says own the AI layer, meter it, that's the margin. And maybe we're leaving money on the table. But metered-AI margin is a rented moat — the second the model gets cheap, the markup evaporates and your users resent every credit.

Giving it away feels lazier and it converts better, because the honest pitch writes itself: "use the agent you already pay for." No one else in our space can say that without blowing up their own pricing page.

Happy to answer anything about the MCP setup, the local bridge, or how the dogfooding worked. Also genuinely curious — is there a builder out there already doing bring-your-own-agent that I just haven't found? Would love to be wrong about the "nobody" part.

— building Swebsy