What "you own your code" actually means in a website builder

Almost every website builder now advertises code export or code ownership. The phrase covers at least four meaningfully different things, and the gap between the best and worst version of it is the difference between a portable asset and a rebuild.

If you are putting client work on a platform, this is worth ten minutes of due diligence up front.

The four levels of "export"

Level 1 — a rendered HTML dump

You get the HTML the visitor sees, usually with machine-generated class names and inline styles, plus whatever CSS and JS the builder emitted. It will render. It is close to unmaintainable by hand, and editing it means abandoning the builder entirely, because changes do not flow back.

This is genuinely useful as an archive or an escape hatch. It is not a codebase.

Level 2 — a proprietary project file

You can download your project, but the file only means anything to the tool that made it. This is a backup, not ownership. If the company shuts down or prices you out, the file is inert.

Level 3 — a real framework project

You get a project structured the way a developer would have written it: components, a routing structure, a build config, dependencies in a manifest. You can open it, run it, understand it, and hand it to someone else. This is the level at which "you own your code" starts to be a truthful claim.

Level 4 — full source, round-trip

Everything in level 3, plus edits made outside the builder can come back in. This is rare and technically hard, and most tools do not offer it. It is worth knowing it exists mostly so you can recognise how much of the market is not offering it.

Questions worth asking before you commit

• Can I export on the plan I am actually going to pay for, or only on the top tier?
• What exactly is in the export — framework project, or rendered output?
• Does the exported site need the vendor’s servers, CDN, or runtime to work?
• Can I host it anywhere, or only on their infrastructure?
• If my subscription lapses, what happens to sites already published?
• Who owns the domain under the default setup?
• Are the fonts and assets licensed to me, or to the platform?

That fifth question is the one that catches people. Some platforms will take a published site offline when billing stops, which means your client’s website is a subscription, not an asset — a fact worth surfacing before you recommend it, not after.

Why this matters more than it sounds

Lock-in almost never hurts during the build. It hurts at two specific moments: renewal, when the price goes up and leaving would mean rebuilding; and redesign, when the client wants something the tool cannot express and the only options are a workaround or starting over.

Both moments arrive eighteen months to three years in — long after the decision was made, and usually to someone other than the person who made it. Choosing for portability is choosing on behalf of your future self.

A fair caveat

Portability is not free. Tools that emit real framework code tend to ask more of you, and a fully managed platform can be exactly the right answer for a small brochure site that will never be touched again. The mistake is not picking a closed tool — it is picking one without knowing that is what you picked.