AI coding agents can now build a marketing site that looks and performs well, which makes leaving Webflow a real option rather than a thought experiment. The build was never the expensive part, though. What decides this is who edits the content next Tuesday, who fixes it at 2am, and whether anyone on your team can read the code six months after it was written.
Key Takeaways
- AI agents have made building a custom marketing site genuinely cheap, which changes the calculation but does not settle it.
- The decisive question is content editing: without a CMS, marketing goes back to raising tickets.
- Hosting, forms, redirects, security updates and uptime become your responsibility rather than the platform's.
- Migrating makes sense for engineering-owned sites, unusual technical requirements or genuine scale problems.
- It rarely makes sense purely to save a subscription fee, since ownership costs replace licence costs.
A year ago this question was theoretical. Now it is not. Founders are describing a site to a coding agent over a weekend, getting something respectable, and asking a reasonable follow-up: why are we paying a platform subscription when this took two days and no designer?
Our bias should be stated plainly. We build marketing sites in Webflow, so we have an obvious interest in the answer. What follows tries to be useful despite that, which means being specific about the cases where leaving is the right call. The short version is that this is a genuine decision with a real answer on both sides, and the answer depends far more on your team than on the tooling. We have written before about where visual platforms fit, and this is the same question asked from the opposite end.
What a Claude or Codex-built website actually means
Worth being precise, because the phrase covers two very different things.
The tools in question are agentic coding assistants. Claude Code reads a codebase, edits files, runs commands and works across a terminal, IDE, desktop app or browser. Codex works similarly across the terminal, an editor and the cloud. Neither is a website builder. They are general development tools that happen to be very good at producing front-end code.
So a site built this way is a normal custom-coded site. Typically a modern framework, a component library, styling of some kind, deployed to a host, with content either hard-coded in the repository or pulled from a separate headless CMS you also have to choose, configure and pay for. The agent wrote the code faster than a developer would have. Everything else about owning a custom site remains exactly as it was.
That is the part the weekend demo hides. You did not replace a platform with a prompt. You replaced a platform with a codebase.
What these tools genuinely do well
It would be dishonest to wave this away, because the capability is real and it has moved quickly.
A competent agent will produce clean, semantic markup, sensible responsive behaviour and accessible patterns if you ask for them. It will scaffold a whole site structure in an afternoon. It handles the fiddly work, animation logic, form validation, build configuration, that used to consume a developer's week. It can integrate anything with an API without the constraint of waiting for a platform to support it.
The ceiling is also higher. Anything you can describe, you can have. No CMS item limits, no plan tiers gating a feature, no waiting for a roadmap. For a site with genuinely unusual requirements, that difference is not marginal.
What these tools do not do is make decisions. An agent will build precisely the site you describe, including the wrong one, and it has no opinion about whether a page should exist, who it is for or what it needs to say. That work is unchanged, and it is most of the work on a marketing site that has to earn its keep.
And the cost of the initial build really does collapse. That is not marketing language, it is simply what these tools do. Pretending otherwise would be the sort of defensive nonsense agencies have been producing about every new tool for twenty years.
The question that actually decides it
Here it is, and it is unglamorous: who publishes the next blog post?
On a Webflow site, a marketer opens the editor and publishes. On a hand-coded site, unless you have built or bought something else, publishing means editing a file in a repository and triggering a deploy. Most marketing teams will not do that, and should not have to.
The usual answer is to add a headless CMS. That works, and it is a real solution. It is also another vendor, another subscription, another integration to maintain, another schema to design, and a separate editing interface that someone has to configure so it is not hostile to non-technical people. You have not removed the CMS problem, you have unbundled it and taken responsibility for the assembly.
This is the same argument in reverse to the one we made about the limits of no-code tools. The visual platform exists to keep marketing out of the engineering queue. Remove it without replacing that function and you have quietly put marketing back in the queue, which is usually the exact problem the site was supposed to solve. A well-structured Webflow build earns its keep here, and so does a well-built headless setup. What does not work is neither.
The costs that move, and the ones that do not
The subscription saving is the first thing people calculate and the least important number in the exercise.
Check the current Webflow pricing and you will find that a marketing site plan costs less per month than a couple of hours of developer time. Against that, a self-hosted site carries hosting, a CMS if you add one, a CDN, SSL management, monitoring, and dependency updates that arrive whether or not anyone has time for them.
Then there is the cost nobody puts in the spreadsheet. Someone has to own the codebase. When a form stops submitting, when a dependency has a security advisory, when the build breaks because a package changed, when the site goes down on a Sunday, there is no support portal. There is you, or a developer you are paying, or an agent you are supervising without the expertise to check its work.
That last case is the genuinely risky one. A site generated by an agent and maintained by someone who cannot read it is a liability with a countdown on it. It works beautifully until it does not, and then nobody in the building knows why.
When migrating makes sense
Several situations where the answer is straightforwardly yes.
Your site is already owned by engineering. If developers maintain it, deploy it and are comfortable in a repository, a platform is adding a layer they do not need. Agents make that path cheaper than it has ever been.
Your requirements have outgrown the platform. Complex application logic, authenticated areas, deep integrations, a content model that is genuinely relational, or a content estate large enough to hit CMS ceilings. These are real limits and code does not have them.
You need something unusual. An interactive tool, a custom calculator, an experience that does not fit the shape of a page builder. Building that outside a platform is often simpler than fighting it inside one.
Marketing does not actually publish. Some companies genuinely update their site four times a year. If that describes you honestly, and not aspirationally, the editing argument mostly disappears.
A pattern worth noticing across those four: none of them is about the build being cheaper. They are about a structural mismatch between what the site needs to do and what a visual platform is shaped for. That is a sound reason to move. Build cost, on its own, is not.
When it does not
And the cases where it is a mistake, which in our experience are more common.
Marketing owns the site and ships frequently. This is the strongest argument against migrating, and it is not close. If someone publishes a page most weeks, taking away the editor to save a subscription is a bad trade.
Nobody in the company can read the code. If the person who prompted the site into existence leaves, and nobody else understands it, you have created a dependency on an individual and a chat history.
The motivation is cost. Licence savings get eaten by hosting, a headless CMS and maintenance time, usually with a net loss once you price the hours honestly.
The current site is simply dated. That is a design problem and a rebuild in any environment fixes it. Changing platforms to solve an aesthetic complaint is an expensive detour.
If you migrate anyway, do these things
None of this is an argument against the move. It is an argument for doing it with your eyes open.
Solve content editing before you write a line of code. Decide where content lives, who edits it and what that interface looks like. If the answer is a headless CMS, choose and configure it first. If the answer is that nobody needs to edit, write that down and check whether marketing agrees.
Treat search equity as a first-class concern. The failure modes are identical to any replatform: URLs change without redirects, metadata gets dropped, internal links break, content is trimmed for tidiness and rankings go with it. You need a URL inventory, a mapped redirect plan, metadata parity and a post-launch crawl. This is exactly the discipline a platform migration demands in either direction, and the reason it belongs alongside SEO work rather than after it.
Insist on tests, documentation and a readable structure. An agent will produce these if asked and skip them if not. The difference between a maintainable codebase and an unmaintainable one is largely what you specified up front.
Verify performance rather than assuming it. Custom code is not automatically fast, and the usual culprits do not change. Image weight in particular is where most real-world problems live, as we covered in our piece on image compression.
Decide who owns it on day one. Name a person or a retainer. A site with no owner degrades quietly, and that is true of every site we have ever seen, including the ones we built. With clients like HockeyStack, a previous client, the ongoing ownership mattered more than any platform decision.
Frequently asked questions
1. Can Claude or Codex really build a professional marketing website?
Yes, with competent direction. Both are general agentic coding tools rather than website builders, so they produce a normal custom-coded site. Output quality depends heavily on the brief, the review process and whether anyone checks the result against real accessibility, performance and SEO standards.
2. Will we save money by leaving Webflow?
Often less than expected, and sometimes nothing. The subscription disappears, but hosting, a headless CMS, monitoring and maintenance time replace it. Price the hours realistically, including who fixes things when they break, before treating this as a cost decision.
3. How will our marketing team publish content without Webflow?
Either through a headless CMS you choose and configure, or by editing files in a repository, which most marketing teams will not do. Answer this before the build rather than after, because it is the question that most often turns a successful migration into a regretted one.
4. What happens to our SEO if we migrate?
It depends entirely on the migration plan rather than the destination. Rankings are lost through missing redirects, dropped metadata, broken internal links and removed content, not through the choice of platform. A URL inventory, a redirect map, metadata parity and a post-launch crawl prevent almost all of it.
5. Is a hand-coded site harder to maintain than a Webflow site?
Usually yes, though the gap narrows if you have engineers. You take on dependency updates, security patching, hosting and uptime, none of which a platform previously charged you attention for. The risk concentrates when nobody in the organisation can read the code the agent produced.
Final word
The interesting thing about this question is that the technology part is more or less settled. AI agents can build a good marketing site, and arguing otherwise is no longer credible. What has not changed is everything surrounding the build: who edits it, who maintains it, who is accountable when it breaks and whether the people responsible understand what they are responsible for. Platforms exist to answer those questions on your behalf, and that service has a price. Leaving means taking the questions back, which is entirely sensible for some teams and quietly expensive for others. Decide based on your team rather than on what the tooling can demonstrate in a weekend, and you will probably get it right. If you want a second opinion on your specific case, get in touch, including if the honest answer turns out to be that you should go.
.jpeg)