A Webflow Alternative for Agency Sites an Agent Already Builds

The short answer

Webflow is a visual builder. You (or a designer on your team) work inside its canvas, wire up a CMS, tune interactions, and Webflow hosts the result. It runs a real agent connector of its own, official and substantial, and that belongs at the top of the page rather than buried in it.

Then look at where that connector stops. Across all three of its tool references there is no backup tool, no restore tool and no rollback tool, and the public Data API's Sites endpoints are List Sites, Get Site, Get Custom Domains and Publish Site, full stop. And the capabilities that touch the design surface carry a second condition, in Webflow's own words: the Bridge App "must remain open for these capabilities to work."

Birta doesn't have a canvas at all. It publishes and maintains a site that already exists, built by whatever agent your workflow already uses, and the connection to that agent is how the product is used rather than a second door onto a dashboard. One connection reaches the draft, the version at its own address, the rollback, and the remarks a client left on the page. Nothing in that loop waits on a person with a panel open.

So if a person is still designing by hand, Webflow's canvas is the stronger place to do it. If an agent already produces the client site, the work that's left is publishing it, keeping every publish reversible, and getting a client to sign off without adding them to your workspace. That is the part Birta does.

What each agent connector reaches

Start with the finding this section turns on. Webflow publishes three tool references, for its data tools, its designer tools and its utility tools, and between them they contain no tool that creates a backup, lists one, restores one or rolls a site back. Not one, in any of the three. The public Data API tells the same story from the other side: its Sites endpoints are List Sites, Get Site, Get Custom Domains and Publish Site, and that is the entire list. Read at developers.webflow.com on 7 September 2026.

Webflow's backups themselves are real and automatic, and they live in Site settings under a Backups tab, where a person previews a version and restores it. So getting yesterday's site back is a human in a browser tab. Webflow's help centre blocks automated reading, so the Backups tab is its published help material as surfaced in search on 7 September 2026 rather than a page we opened.

The second finding is Webflow's own setup instruction, worth quoting in full. For the capabilities that run against the Designer, the documentation tells you to "open your site in the Webflow Designer, launch the Webflow MCP Bridge App from the Apps panel, and wait for it to connect to the MCP server. You can minimize the App once it connects, but it must remain open for these capabilities to work" (developers.webflow.com/mcp/reference/how-it-works.md, read 7 September 2026). A connector that needs a person keeping a panel open is a connector fitted onto a product that already existed.

None of which makes it a token effort, because it isn't one. Its developer documentation puts the server at mcp.webflow.com/mcp over OAuth, with plugins or connectors for Claude Code, Claude Desktop, Cursor, Windsurf, Postman and Slack, and an official Webflow app in ChatGPT. The data tool reference lists 24 tools, and between them they cover sites, pages, elements, styles, components, variables, CMS collections and their items, assets, custom fonts, custom code, forms and their submissions, SEO and schema markup, sitemap status, webhooks, traffic analytics, and comment threads. One of them publishes the site.

It reaches further into design than ours ever will. An agent holding it builds the page itself: add an element, set a heading level, swap an image, replace a class's CSS. It also reaches four things ours doesn't, and those deserve naming rather than glossing. Page branches, for working a change in isolation. A draft state per page. CMS items that stay drafts until a separate publish call. And a reply posted into a comment thread, which its tool reference describes as a way to "Reply to a thread programmatically as part of a review workflow." Our agent cannot do that last one at all, and the sign-off section below says exactly how far that goes.

Birta was assembled from the other end. The connection isn't a second route onto a panel, it is how you use the product, so one connection carries the whole loop. Copy a stored version into a draft, edit the files in it, publish it as a new version at its own address, list what went out before, put an earlier one back live, read the remarks somebody left on a version. The restore sits inside the connector rather than beside it, and no step in that list asks anyone to keep a Designer session connected while it runs. What Birta gives up for that is everything Webflow's design tools do, which is a lot.

Nobody imports a Webflow site into Birta

Birta has no Webflow importer. No connector, no bring-in-my-project button, nothing that opens a .webflow.io address and reads what it finds. That is a decision rather than a backlog item, and it holds for every other source too.

The reading half of this job already belongs to the agent you talk to. Webflow's code export hands you a folder of static HTML, CSS and JavaScript, and Claude Code, Cursor, Codex and Claude Cowork all read folders off your disk without being asked twice. A web-capable agent can also just open the published site and pull the copy and markup off the page.

There's a third route now, and it's the tidiest of the three: connect Webflow's own server to the same agent and let it read the site from the inside. Its tools list the pages, walk the element tree and list CMS items, so the agent can pull the real content instead of scraping rendered HTML. Building a Webflow reader into a publishing service, when Webflow already ships one, would buy you nothing.

So Birta starts where the files already are. It gives them a real address, a version history you can roll back, remarks a client leaves on a version, a declared lead form, a domain and a visitor count. It will not read your Webflow project for you, and it does not need to.

Which is also why the migration section further down is a rebuild rather than a transfer. What comes out of Webflow is code and content; turning that into the site you actually want is the agent's work, not a platform feature either side ships.

Compare the work after the first publish

Once a site exists, the two products manage very different things around it.

Webflow's CMS and interaction system are real capabilities Birta doesn't have, and its connector reaches most of its own product. What the table draws is where each connection stops. Two rows on Webflow's side stop outside it: the restore, which is a Site settings job with no tool and no endpoint standing behind it, and the review, which needs a reviewer invited into the workspace first. On Birta the version history, the downloadable archive, the declared lead form and the review remarks all answer to the same conversation that published the site.

Getting a client to sign off on a version

Webflow is not empty here. It documents a Reviewer role that costs no paid seat, where the reviewer opens the site in a comment-only view, drops a pin on the element they mean, and can reply in a thread and mark it resolved. Someone without a Webflow account can take part as well, after verifying their email address. All of it happens inside Webflow, in the workspace you let the reviewer into. Webflow's own site blocks automated reading, so this is its published help centre and University material as of 7 September 2026 rather than something we tested.

Two things separate the two rounds: what a remark attaches to, and who has to be let in before leaving one.

On Webflow it attaches to the project as it currently stands, and somebody in the workspace has to invite the reviewer in first.

On Birta a remark attaches to a version. Every version, draft or published, has its own permanent address, handed to the agent when it opens the draft and again when it publishes. You send that address and nothing else. Whoever holds it opens the page without signing in, without a seat and without an invitation, because version links are open to the link holder by default. The guest is issued a nickname, and that is what signs their remarks.

Then they mark up the page itself. They click the heading, the price, the wrong button, and the remark pins to that element on that version.

Your agent reads them back through the same connection it published with. Each thread arrives with its number, the page and element it points at, whether it is still open, and every message with author and time. Thread numbers are permanent, so "number three is still open" still names one specific remark next week. The agent makes the changes in the same draft, publishes a new version, and the reviewer refreshes the tab they already have open.

Webflow has more room here than we do, on both sides of the seat. Its reviewer closes the thread they opened. Its comments tool documents create_reply, offered for exactly the job you would guess, to "Reply to a thread programmatically as part of a review workflow," so an agent on Webflow answers in the thread. Ours cannot. Our agent only reads remarks, and a write to a thread comes back refused with a 403, so replying to one and closing one both stay human actions in a browser. Resolving is the single action absent from Webflow's tool list, although its Data API does carry an endpoint for it.

What our agent does instead is the step after the remark. It reads the numbered thread, edits the same draft it published from, and puts up a new version at its own address, with nobody opening an editor and nobody holding a session open for it.

Remarks also go out by mail. Everyone with access to the project gets one digest roughly 15 minutes after the first remark lands, minus whatever they wrote themselves. No plan gates any of this, it works the same on the free tier, and the walkthrough is in the versions and remarks guide.

For an agency the practical fork is the seat and the freeze. A Webflow round happens on the live project with the client let into your workspace. A Birta round happens on a stored version at its own address, so what they marked up is still exactly what they marked up when you come back to it on Thursday.

Stay on Webflow when...

Stay when the CMS is doing real work. Collections, dynamic pages, filtered lists: none of that exists on Birta, which only publishes the static files an agent hands it.

Stay when someone on the team designs by hand and wants that control. Webflow's canvas, breakpoints, and interaction system reward a person who is actually tuning the visual details, not an agent generating output once.

Stay, too, if what you want is an agent working the design surface itself. Webflow's connector does that, element by element and class by class, and Birta has no design surface for an agent to touch. Its agent writes files. The price on Webflow's side is the Bridge App sitting open in the Designer while that part runs, which is fine if you were going to have the Designer open anyway.

Stay when Ecommerce is part of the site. Webflow's product listings, cart, and checkout are built into the platform. Birta has no equivalent, and it cannot take a payment from your site's visitors yet. That one is a planned backend module rather than a permanent no, but planned is not shipped.

And stay if the client relationship already runs through Webflow's ecosystem, its component marketplace, its editor permissions for non-technical clients. Moving away from a working setup has a real cost, and that cost should buy something the agency actually needs.

Birta fits better when...

Birta fits an agency or freelancer whose agent already produces the client site, and where the work that's left is publishing it, keeping it current, and handling what happens when a visitor fills out a form.

Choose it when a bad update needs to be reversible without redesigning from memory. Every successful publish becomes a version, the last 10 stay available, and any of them can go live again with the original files intact.

Choose it when the deliverable needs to leave the platform on demand. Each of those saved versions downloads as one archive containing exactly what was published, useful for a backup, a local continuation, or handing the raw files to a client who insists on owning them outright.

Choose it when a real form belongs on the site and someone needs to see the submissions without wiring up a separate tool. The agent declares the fields, and every lead lands in the project panel with an email digest following close behind.

The tradeoff is the same one stated above: no CMS, no visual canvas, no Ecommerce, and no way to take a payment from a visitor yet. Birta is narrower on purpose, and the narrow part is everything that happens once the files exist, all of it inside the one connection your agent already holds.

Moving from Webflow

Webflow's own code export is a reasonable starting point, but it doesn't carry everything. If you'd rather not use it, connect Webflow's server to your agent and have it read the pages, elements and CMS items straight out of the project instead.

What survives: the static HTML for each page, CSS, JavaScript (including the animation logic Webflow generates), and your uploaded images and fonts. That output is plain, editable code you can open anywhere.

What doesn't survive: CMS Collections and Ecommerce content export as empty shells rather than working pages, since both depend on Webflow's own backend to render. Forms will still look right but won't submit anywhere once they're off Webflow's infrastructure. If the client site leans on any of those three, plan to rebuild that part rather than expecting the export to carry it.

1. Step 1Get the content outPull the static export, or connect Webflow's own server to your agent and read the pages and CMS items from the project. Either way, note what depended on the CMS, Ecommerce, or native forms.
2. Step 2Rebuild what didn't exportHand the static files and a description of the missing pieces to your agent, and have it rebuild the form and any dynamic content as part of the new site.
3. Step 3Publish and verifyPublish through Birta, check every page and the form submission, then move an owned domain's DNS once the new site passes review.

So it's a rebuild of the dynamic pieces plus a straightforward carry-over of the static ones. What you land on is worth the trip: from the first publish onward, every change, every version and every client remark runs through the same conversation, with no canvas to reopen.

The decision

Webflow is the right call when the site needs a CMS, Ecommerce, or ongoing hand-tuned visual design, and someone on the team is doing that design work directly.

One line has held across every vendor connector we have read tool by tool, Webflow's included. An official agent connection is normal now. A review round exists on several of them. Not one reaches a version history a connected agent can list and put back live, and that is the piece that decides how a bad afternoon ends. Webflow puts a second condition on top of that, because the capabilities touching its design surface want a Designer session held open while they run.

Birta is the better fit when an agent already builds the client site and the job left is publishing it, keeping a real version history, and giving it a working lead form, without asking anyone to learn a visual canvas or hold a panel open to do it.

Frequently asked questions