I was reading Wix’s announcement of Studio Two (introduced on 2 November), and one line made me stop scrolling: “Export it as a standard React project, keep working in Claude, Codex, Cursor or any IDE, then bring it back.” A website builder, whose whole business for 20 years has been “you don’t need to touch code”, is now offering to hand your site to your coding agent. That’s a big deal, and I think it says a lot more about where SaaS is going than about websites.

So I did what any engineer does with a shiny announcement: I skipped the marketing page and went to the docco. And the docco is where it gets interesting.

What You Actually Get

First of all, credit where it’s due, because the export is properly thought through. According to Wix’s developer documentation, the export (still in beta) is a complete, runnable Yarn workspace. It ships with an AGENTS.md and a CLAUDE.md, an editing skill in .claude/skills/wix-site-edit, a catalogue of every component the site can use, and one “contract” file per component describing its props and the CSS properties you’re allowed to set. In other words, Wix has written the instructions for your agent, so you can say “add a pricing page” in plain English and the agent knows the rules. Neat, huh?

That’s agent experience done well, and most SaaS vendors are nowhere near it. Bear in mind, Wix already has an MCP server that lets Claude manage products, bookings and blog posts on a site. Put the two together and the agent can work on both the code and the business data.

Now Read the Small Print

Here’s the thing though. Those agent instructions tell the agent to make every change “in a form Studio Two can import”. The editing skill is a set of rules for staying inside Wix’s world, so the code you take away is React, but React written in a particular style, mapped one to one onto what the Wix editor understands. And the hosting part is spelt out quite candidly: “Hosting is independent of Wix, but the running site isn’t. It loads fonts and media from Wix and calls Wix APIs for any business features on the page. Think of an exported site as a frontend you host for a site Wix still runs.”

Add the current limitations (sites with dynamic pages can’t be exported at all, and visitors can’t log in to an exported site) and you get the picture. You can take the frontend home. The shop, the bookings, the members, the media and the data stay where they were.

Don’t get me wrong, I’m not having a go at Wix. That’s a perfectly sensible design, they’re honest about it, and a frontend you can version, branch and hand to Claude Code is a real step up from a drag and drop editor. But let’s call it what it is: the lock-in hasn’t gone anywhere. It moved, from the editor to the backend.

The Same Week, the Same Pattern

What made me want to write this up is that Wix isn’t the only one doing it. On 28 October, Readwise launched Readwise Books, an ebook store and reading app with a public API and an MCP server, so your own agents can get to your library, highlights and reading sessions. “Your reading data is yours”, says the announcement, and it takes a well deserved swipe at Amazon for removing the option to download purchased Kindle books in February 2025. Good for them.

But the books themselves? Publishers require DRM, and Readwise says plainly that “you can’t transfer an ebook purchased in one platform to another”. So once again: the data flows freely to your agent, the core asset stays put.

Two very different companies, one week, the same move. Open the edges to agents, keep the core. And I don’t think that’s a coincidence.

Why Vendors Are Doing This Now

I’d argue it’s because coding agents have changed the maths of leaving. When I was a CTO, the real cost of moving off a SaaS product was never the licence, it was the months of engineering time to rebuild the thing and migrate the data. That cost is collapsing. Nowadays a small team (or one stubborn founder) with Claude Code can rebuild a marketing site, an internal tool or a back office app in days, not quarters. So once a SaaS bill gets big enough, somebody in the room asks “how long would it take us to just build this?”, and more and more often the honest answer is “a few weeks”. That’s why I believe the expensive SaaS players (HubSpot, Salesforce and the likes) are on borrowed time: when the price is high, in-house tools written with agents win.

Vendors can see that too. If your customers’ agents can rebuild your product, the worst thing you can do is be the walled garden they’re itching to escape. So you open a door: an export, an API, an MCP server. You make yourself agent-friendly, which is good for everybody. And then you quietly make sure the bit that’s hard to rebuild (the payments, the bookings engine, the content licences, the hosted data) stays on your side of the wall. Smart, to be honest.

What I’d Do as a CTO

If you’re buying software nowadays, I’d add a few questions to every vendor review:

• What can my agent do without your UI? Is there an API or MCP server, and does it cover writes as well as reads?
• When I export, what still calls home? Read the hosting and limitations sections of the docs, not the launch post.
• Could my team rebuild the part we actually use, with agents, in a month? If yes, the price had better reflect that.
• Where does our data live, and can we get all of it out in a format our own tools can read?

And if you’re the one building a SaaS product, the lesson cuts the other way. Your moat used to be the UI people had learnt and the data they couldn’t move. Agents make the first irrelevant and the second visible. The vendors who’ll do well are the ones whose core is genuinely hard to rebuild, and who are relaxed about letting you leave with everything else.

Bottom line: an export button is a welcome thing, but always check what it leaves behind. I haven’t had my hands on Studio Two yet (it’s going to Wix Partners first), so if you have, drop me a line and tell me how far the exported code really gets you 🙂