You don't have to quit your website builder. Change how you build.

Keep the Tilda account. Keep Webflow. If your clients sit on Wix and know where to click, leave them there.

Nothing in the last two years made your builder stop working. The sites you shipped still load, the clients who pay the retainer still pay it. Worth saying out loud, because most of what you read implies the opposite.

What changed is not what you make sites with. It is which part of the work is yours. For years you sold two skills on one invoice: deciding what the site should be, and assembling it by hand. The second got cheap. The first did not.

In practice: the agent does the first pass, you edit, cut and decide, the finished files go to an address, and your builder is still there for the clients who need it. There are more of those than the timeline admits.

Below: what shifts in a working week, what does not shift at all, and the cases where your builder is still the correct answer.

The question was never which tool

The pitch you keep getting is a swap: leave the thing you know, arrive at the thing we sell, bring your clients. Migration stories are frightening because they ask you to bet a working practice on a slogan.

But a tool and a method are different objects. The tool is what holds the site: where it lives, who edits it, what the client logs into. The method is how the site comes to exist, the sequence from a phone call to something you will put your name on. Almost all of the anxiety is aimed at the tool. Almost all of the change is in the method.

A second confusion is tangled up in it. An AI website builder and an AI agent are not the same species. The builder is a canvas with generation bolted on, and it owns the result. An agent is something you already talk to: no canvas, just ordinary browser files that then have to go somewhere. That difference decides most of what follows.

What every "AI vs website builders" page is actually selling

I read the whole front of the query "ai vs website builders," nineteen results, before writing a word of this, because that corpus is where the pressure you feel comes from.

Just over half are head-to-head comparisons, and nearly all of the front page explains before it pitches. But among the comparisons I could not find one published by a company without something to sell in the answer.

That is a genre, not an accusation. Durable's comparison walks setup, content, design control, learning curve, cost, SEO, scaling, maintenance and commerce, then ends on Start for free. Momentum's piece on the limits of AI web builders argues the opposite case and ends on schedule a consultation with their design studio. Both are internally consistent. Both are advertisements.

Some are genuinely good. DreamHost's version refuses the binary, arguing "the real choice now has three paths, not two," and is honest about what a closed platform costs you. Playcode lands on a hybrid. AI Marcus did the harder thing and built the same bakery site four ways before writing about it.

The pattern took reading all of them to see: every one is written for somebody who has not chosen a tool yet. They are buyer's guides, addressed to a reader standing at the start. Not one is addressed to a person who already has the tool, the skill and the clients on it. That reader does not appear in the results.

The telling detail is what sits at the top. The first result is not a vendor page. It is a thread in r/web_design titled "What's your thoughts on ai website builders?? Useful or trash??", practitioners asking each other, because the published material was written for somebody else.

The part of your week that actually changes

Concretely, then.

The first pass changes: the stretch where you have the brief and the job is putting it there, sections, structure, the first honest draft of the copy, a layout that holds together. That was hours of assembly. It is now a conversation followed by editing.

The second and third rounds change. Testimonials above the pricing, a different headline, one more service block. That was rearrangement. It is now a request.

The repeat job changes most. If you have built roughly the same shape of site eleven times, the twelfth is mostly recall, and recall is what these tools are good at.

That adds up to a change in category: from producing to editing and deciding. Editing is the harder skill, which is what the doom posts get backwards. Anyone can generate a page. Knowing which of four versions is worth showing a client, and which one is quietly wrong, is trained judgement that stopped being expressed through dragging.

Note what is not in that list: any claim about how much faster this makes you. I do not have an honest number and neither does anyone selling you a comparison table. The same restraint applies to your rates. A faster first pass changes your cost, not the client's price, and the margin math is worth running before you quote differently.

The part that does not change

The call where the client explains their business badly and you work out what they meant. The judgement that their real customer is not the one they described. The offer: what is sold, to whom, for how much, why anyone should care. The decision to cut the section they were attached to. Knowing what "make it pop" means for this person. The final read where you catch the thing that is technically fine and commercially wrong.

And the responsibility. When the site underperforms, nobody accepts "the agent wrote it."

An agent has access to none of this. It does not know the client's competitor opened across the street, that the last designer burned them, or that they are lying about their target audience to protect their pride. That has always been the work.

Where your builder is still the better answer

This is the part most articles skip, so, directly: there are ordinary client situations where an agent-built site is the wrong recommendation.

Keep the builder when the client edits their own pages. If they change the menu, swap the seasonal photo and add a staff bio without calling you, they need a visual editor and a login. Handing them a conversation instead is not a favour.

Keep it when the site needs bookings, a store, memberships or editor roles. Those are running systems, not finished pages, and the platforms that do them well spent years getting there.

Keep it when you have a design system inside the builder: shared styles, components, a template every client site inherits. That is accumulated capital.

Keep it when the client pays for the platform anyway and lives in its dashboard, with the site next to their contacts and invoices.

An agent plus a publishing layer does not do those jobs and is not trying to. The longer version of the argument, where a full platform earns its subscription and where it does not, is in the builder comparison, including the part worth repeating: do not migrate a working site for sport.

For the feature level, take the builder in question. Webflow covers what changes after the first publish and what survives a move off its CMS. Wix states plainly what a move involves, since Wix exports no design. Squarespace is what the subscription actually buys and what its export carries. Durable walks the whole module set and the one workflow it has no path for. Google Sites is the shortest argument of the five: it is free, its custom domain is free, and the only question is whether an agent is doing the work, because no agent can publish to it.

One correction while I am here. That builder comparison framed the choice around a single landing page, which platform to pick for one job. Fine for the job, wrong for you. Somebody with a book of client sites is deciding what to do with a practice.

Where the agent path stops, and what fills the gap

Follow the method to its end and you hit a wall. The agent produced the site, the files are correct, and now it needs an address, a certificate, your client's domain, and a sane way to make the change they will ask for on Thursday.

None of that is what an agent does. It is a separate layer, and it is the one Birta occupies: the step after the agent. No canvas; Birta's own agent works in its chat, or you bring the one you already use. The finished files get published to a live HTTPS address, your own domain points at it, the last ten published versions are kept so a bad change can be undone, and the next edit goes through the agent in Birta or the conversation that made the site.

If you want the wider argument about why that layer should exist, it is in vibe deployment. If the mechanics of how an agent connects are the unfamiliar part, start with what MCP is.

How to try this on one site without touching your clients

The way to evaluate a method is to run it once, on something small, where being wrong costs you an evening.

1. Step 1Pick one small site you would have built anyway

   Your own portfolio, a friend's one-pager, the tiny job you would knock out on a Saturday. Something with a real brief and no revenue attached.

   If you choose the portfolio, review the result with the portfolio clarity lens: identity, work proof, your role, and the next action. It is a stronger test than whether the first screen looks fashionable.

2. Step 2Do not touch anything that is already live

   Every existing client site stays exactly where it is, on the platform it is on. Nothing gets migrated. This is a parallel experiment, not a transition.

3. Step 3Describe the outcome, not the markup

   Tell the agent who it is for, what is being sold, what the sections are, what you want the visitor to do. Brief it the way you would brief a junior, because that is the skill being tested.

4. Step 4Publish it and look at the real address

   Not the preview. Open the live URL on your phone, the way a client will. This is where you find out whether it is genuinely finished.

5. Step 5Point a domain at it, if there is one

   Same job as always: one record where your DNS lives. The custom domain guide covers apex versus www and why verification stalls.

6. Step 6Make one change the way a client would ask for it

   Ask for the edit in Birta's chat or the conversation that built the site, publish it. Updating a live site is the part worth judging, and if the change makes it worse, restore the previous version instead of repairing it by hand.

At the end you will know something concrete about your own work, from your own hands, rather than from a comparison table written by somebody who wants your subscription. If the answer is no, you have lost one evening and migrated nothing.

If it goes the other way, building a site without a builder runs the whole path end to end, including how a client marks up the draft before it goes live.

Frequently asked questions