Webflow to code you own.

[ Why teams move ]

Nothing broke. Your team outgrew the way the site gets changed.

Webflow is genuinely good at what it was built for, and most teams who leave were well served by it for years. What changes is rarely the platform. It’s the team. The site becomes a growth channel, more people need to touch it, and the things that made it easy start deciding how fast you can move.

It shows up in the same places. The change that needs a developer anyway, because the interaction you want isn’t one the Designer can draw. The CMS structure you need and the plan you’re on don’t allow. The bill that grows with every seat and every workspace. And now a newer one: your team works with AI every day, and the website is the one place its agent can only reach in from outside.

[ Is it time? ]

Three signs your site has outgrown Webflow.

Your team uses AI every day, for everything except the website.
Changes queue behind the one person who knows how the site is wired.
You’re paying more each year for a site you can’t take with you.

And it’s fine to stay if the site changes a few times a quarter and your designers love the canvas. We’ll tell you which on the Discovery call, with the evidence from your own site.

[ The path ]

From Webflow to an agentic website, in six steps.

Step 1

Map your Webflow site.

Discovery reads the site as it stands: the page templates, the collections and how they reference each other, the interactions, the forms, and every live URL. You leave with a roadmap that says what moves, what it becomes, and in what order.
Step 2

Rebuild the design as a system.

Your Webflow classes, variables and components are rebuilt as a component library in code, with the rules for using them written into a brand.md. A site built on a framework like Client-First or Lumos maps across cleanly. One built page by page gets tidied on the way. Every page is checked against the live one, side by side.
Step 3

Move the content into your repository.

Each CMS collection becomes a set of structured content files, with references, rich text and image fields mapped one at a time. From here your content sits next to the code, under your name, where your agent can read all of it.
Step 4

Add the rails and the machine layer.

The guardrails and skills your agent will run on go in: what it may touch, how a page gets built, what gets checked before anything ships. So do the parts Webflow only partly allowed: structured data, schemas, llms.txt and a clean sitemap, done completely.
Step 5

Switch over, with a net.

The redirects go live with the switch, so no URL is ever without a destination. Your Webflow site keeps running untouched until the moment the new one takes over, and the Webflow plan isn’t cancelled until you’ve watched the new site run.
Step 6

Take the keys.

Your team connects the agent it already uses and ships its first supervised changes in the first week of handover: a real page, a real edit, with us in the room. From then on the Designer seat is no longer the queue.

[ Piece by piece ]

What each part of your Webflow site becomes.

	On Webflow	On an agentic website
[ 01/ Design ]	Designer classes, variables and styles	A component library and a brand.md your agent builds against
[ 02/ Content ]	CMS collections, inside your plan’s limits	Structured content files in your repository. The repo is the CMS
[ 03/ Interactions ]	Built in the Designer’s interactions panel	Rebuilt in code, component by component
[ 04/ Forms ]	Webflow forms, tied to Webflow hosting	Rebuilt and pointed at your CRM or form handler
[ 05/ URLs and rankings ]	Webflow’s URL structure and sitemap	Every URL redirected, metadata carried over, rankings watched through cutover
[ 06/ Hosting ]	Webflow’s hosting, on Webflow’s plan	Hosting in an account under your name
[ 07/ Making a change ]	Ask the one person with Designer access	Brief the agent, check the preview, approve it
[ 08/ Adding a teammate ]	Another seat on the bill	No seats. The cost of shipping stays flat
[ 09/ When something goes wrong ]	Hope the change didn’t break something	A broken layout fails before it ships, and any change can be undone

[ The agent layer ]

On Webflow, your agent is a guest. On your own code, it’s an editor.

Webflow gives an agent more than most platforms do. Its MCP lets an agent read and change pages, components, CMS items and settings, and on a well-built site that’s real help. But it works through what the platform exposes, inside the platform. It can’t see the whole site as code, can’t run it, and can’t check its own work before it ships.

On an agentic website the site is plain, structured files in your repository, so the agent your team already uses, Claude, Claude Code, ChatGPT, Gemini, Cursor, Codex, reads all of it and changes any of it. It builds inside your encoded brand and our rails, and the change arrives on a preview. The AI proposes, you approve what ships. A new campaign page becomes a brief, not a ticket, and adding ten marketers doesn’t add to the cost of shipping.

[ Where you land ]

An agentic website: yours, and run by your team.

The keys.

Code and content in your GitHub repository, under your name, from the first commit.
Your agent ships it.

Your team briefs the change in plain language and it lands on a preview. The AI proposes, you approve what ships.
Your brand, encoded.

A brand.md in the codebase, so every change, from anyone, is made against your rules.
Our standards, baked into the rails.

More than a decade of design and development standards, checked before anything ships.
The machine layer.

Structured data, schemas, llms.txt and a clean sitemap, so the AI systems answering your buyers can read and cite your site.
The handover.

Playbooks and paired working, until your team runs the site themselves.

[ Recent work ]

Built for SaaS teams like yours.

Autohive: a website that keeps pace with their marketing teamAn AI-agent company's first website, built on a component framework their designers, marketers and agents could all work in, so their marketing team builds its own landing pages and updates without waiting on anyone.Read more
Future of Marketing Work: a brand and website for a three-way eventAn Auckland event on how marketers adapt to digital transformation and AI, brought together by a university, the AI community and an events group. We made the brand, the website and the print.Read more
Landlord Studio: one system for two markets, run by their marketing teamProperty management software for landlords in the US and UK. A five-year-old Webflow build redesigned, migrated onto a component-driven framework, and handed to a marketing team that now builds its own pages with AI.Read more

Will we lose our rankings moving off Webflow?

A migration is built to keep them. Every live URL is mapped to its destination before anything moves, metadata travels with it, and rankings are watched through cutover so anything that shifts is caught and fixed. Webflow’s URL structure is clean and its sitemap is reliable, which makes this the predictable part of the move.

How long does a Webflow migration take?

The roadmap sets the timeline. It depends on the number of templates more than the number of pages. What stays fixed is the cadence: something visible ships every fortnight, from the first fortnight, on a live preview.

What happens to our Webflow CMS collections?

They land as versioned files in your repository, next to the code. Fields are mapped one at a time, rich text, references, image fields, so the structure survives rather than being flattened. After the move your agent edits them directly, and there’s no plan limit to design around.

Webflow has AI features and an MCP now. Isn’t that enough?

For some teams, yes, and we set it up on every Webflow site we build. The difference is reach. On Webflow the agent works through what the platform exposes. On code you own it works on the site itself: it can see all of it, run it, and check its own work before anything reaches a preview. If your team wants the agent doing the legwork across the whole site, that’s the case for moving.

Can our team still make changes ourselves?

More than before. Anyone on your team describes the change in plain language, the same way they’d brief a designer. The agent builds it inside your encoded design rules and it arrives as a preview for someone to approve. Nobody writes code or opens a terminal, and nothing ships without a person saying yes.

What’s the alternative to Webflow for a marketing team?

The usual answers are another site builder or a headless CMS, and both keep someone else’s platform between your team and your site. The third option is to own it: the site as code in your own repository, with your team’s agent making the changes inside rules we set, and a person approving each one. That’s an agentic website , and a migration is how most teams get there.

Can’t we just export our Webflow site’s code?

You can export the HTML, CSS and JavaScript, and it’s a fair question. What the export leaves behind is the part that makes the site work: the CMS content, the forms and anything the hosting was doing for you. And what you get is a snapshot nobody was meant to edit, not a system. A migration rebuilds the site as components your team and your agent can keep building on.

What happens to our Webflow interactions and animations?

They’re rebuilt in code, one component at a time, and checked against the live site. Most come across exactly. Where an interaction was a workaround for something the Designer couldn’t do directly, it usually gets simpler.