Working with AI
Two Days, One Website (and Three More Days Cleaning Up)
I rebuilt this site with Claude Design in two days, then spent three more on the deployment. The fuller account: dead ends and where AI stops being enough.
3 May 2026 · 10 min read · By Sophie Kazandjian
In two days I rebuilt my entire website with Claude Design and migrated it from Squarespace to Cloudflare. The migration after that took another three days of unglamorous untangling, and that part is the bit nobody writes about. So I'm writing it.
The old site had become a cage
I'd been on Squarespace for years. It served a purpose. When I started Sophie's Bureau I needed a site that worked, that I could update myself, and that didn't require me to think about hosting or DNS or any of the plumbing underneath. Squarespace gave me that.
But the gap between what I wanted and what the platform would let me have grew wider over time. I write about calm, considered, human-led digital operations. I help clients audit the tools they use and choose with intention. And there I was, paying €28 a month for a website that, no matter how much custom CSS I layered on top, still felt like it had been poured into a Squarespace-shaped mould. The grids gave it away. The spacing gave it away. The way the navigation behaved on mobile gave it away.
The cost was the smaller part of the frustration, although €336 a year for a site I had outgrown was hard to justify. The bigger part was the design ceiling. I could feel where my ambitions stopped and the template's defaults began, and that ceiling was getting lower every time I learned something new about what good websites can be.
What changed
What pushed me to do something about it wasn't a renewal email. It was the launch of Claude Design, Anthropic's new product for building visual work through conversation. I'd already been using Claude in the standard chat interface for months of client work: newsletters, a slide deck from raw data, an email signature, a paid web app protected with Cloudflare Workers. Each project taught me a little more about what was possible. But Claude Design changed the shape of what could happen in a single sitting. Real typography decisions. Real layout judgement. A canvas to iterate on rather than copy-pasted code blocks. The website I'd been carrying around in my imagination, the one I could never quite buy off-the-shelf, was suddenly within reach.
So one morning I opened a new project and started.
What two days actually looked like
Day one was structure and language, all of it inside Claude Design. We worked out the architecture together: the homepage, the journal, the case studies, the FAQs, the legal pages, the French version of the site. We made decisions about what would be a clean URL and what would be a section anchor. We chose a typography system, a colour palette built around cream and sage and clay, a way of laying out long-form articles that would feel like reading something considered rather than scrolling something automated. I made a thousand small calls and Claude Design made the ten thousand smaller ones underneath them, refining each component live as we talked.
Day two was migration and detail. We exported every article from Squarespace, parsed the export file, and rebuilt thirty-seven journal pieces inside the new system. We built a custom journal index, a category filter, a portfolio of case studies, a French homepage, a 404 page that doesn't feel like a punishment. We chose a redirect strategy on paper. The site looked, on my local machine, like the one I'd been carrying around in my head.
That part, the building part, was as good as the breathless AI commentary suggests it might be. What I want to write about now is the part that comes after, because that's where most of the real lessons are.
The deployment was a different kind of work
Pushing the new site to Cloudflare Pages and pointing the domain at it is, on paper, a five-minute operation. In practice, between Sunday morning and Wednesday evening, I worked through a long sequence of small but compounding problems. For this phase I switched out of Claude Design and into the regular Claude chat interface, running on Claude Opus 4.7. Design canvases are not the right tool for reading curl traces and chasing redirect loops; the chat is.
The first problem was that my clean URLs didn't work. Visiting /portfolio or /faqs returned a 404. The fix was a _redirects file that maps clean paths to the underlying .html files, and once I had it in place, those pages started loading.
The second problem was that I'd advertised every old journal post in my sitemap as /digital-ops/<slug>, but the redirect rules I had only knew about /journal/<slug>. So Google's indexed URLs were broken. I rewrote the redirect rules to cover the four different URL prefixes Squarespace had used over the years: /virtual-assistant-blog, /virtual-assistant-website-design-tips-tools-case-studies, /web-design-portfolio, and the old plain /blog. The rules also handled the twenty-three articles I'd retired during the rebuild, which needed to redirect to the journal index rather than to broken slugs on the new site.
The third problem was an infinite redirect loop on /portfolio and /faqs. The redirects file was sending /portfolio to /portfolio.html, and Cloudflare Pages, being helpful, was rewriting /portfolio.html back to /portfolio for clean URLs, and the two were arguing in a perfect circle. The browser hit its redirect cap and gave up. I rolled the deployment back, removed the rewrite rules entirely, renamed the underlying files to match what Pages expected, and the loop dissolved.
The fourth problem was that all thirty-seven journal articles started returning 404s. The cause turned out to be that when I'd renamed the files to add .html extensions, Windows had been hiding extensions from me, so I'd accidentally renamed already-extensioned files to something.html.html. Two minutes to spot, ten minutes to fix, an hour to find.
The fifth problem was that the homepage links pointed to /journal/<slug> rather than /digital-ops/<slug>. The redirect rules I'd written would have caught these, but only at the cost of an extra hop on every click, and the inconsistency meant my prev/next links inside articles were also wrong. I did a project-wide find-and-replace.
That find-and-replace is the sixth problem. VS Code's regex mode was on when it shouldn't have been, and the asterisk character has a special meaning in regex, and somewhere in the chain of substitutions I performed, the closing quote on the "Back to Journal" link in every article got replaced with an asterisk. The <meta property="og:image"> tag in the head of every article also lost its closing slash. So all thirty-seven articles deployed with broken JSX that React refused to render, and visitors saw blank pages with /> floating in the source.
I rolled back the deployment again, asked Claude Opus to write a Python script that fixed the exact damage pattern in all thirty-seven files, ran it, verified each one by hand, and redeployed.
The seventh problem was that my own computer kept showing DNS errors that nobody else's computer was showing, which meant I spent a couple of hours debugging a site that was, from everywhere except my desk, working fine. Flushing DNS cache fixed it.
The eighth problem was the French homepage missing its mobile burger menu, because the French version of the nav component had been written before the mobile drawer was added to the English one and never got brought into line. The fix was a careful copy of the structure across.
I'm telling you all of this not because I think it's especially dramatic. These are ordinary deployment problems and any developer reading this is nodding along. But the AI-and-a-weekend version of the story leaves them out, and that omission is doing real damage to people who try this and then think they've personally failed when the inevitable rough edges arrive.
What this taught me about working with AI
If I'd typed "rebuild my website" into Claude Design and walked away, I'd have got back something competent and entirely generic. What made the rebuild work was the steady stream of human decisions running through every step. Whether to keep a particular old article or quietly retire it. Which words on the homepage carried weight and which were filler. When a colour felt right and when it felt borrowed. Which design quirk was a feature and which was the AI trying to be helpful in a way that didn't match the rest of the site.
The deployment phase taught me something more uncomfortable, though, which is that working with AI doesn't reduce the need for technical understanding. It relocates it. I didn't need to write the code. I did need to read the code well enough to know what was going wrong when it broke. When the redirect loop appeared, Claude Opus proposed three different solutions before I read the trace carefully enough to spot that Cloudflare Pages was generating the loop itself, not the redirects file. When the find-and-replace destroyed thirty-seven files, the recovery required me to understand exactly what string had been replaced with what, in what order, before any fix was possible.
There's a tendency to talk about AI as if it removes the need for expertise. My experience this week was that it removes the need for expertise to produce the work, but increases the need for expertise to steward it. Producing is now extraordinarily cheap. Stewarding (knowing what the work is supposed to be, noticing when it isn't that, reading errors with the right kind of attention, understanding enough about the system to ask the right diagnostic question) is where the value sits.
Practical notes if you're considering something similar
The migration is the hard part, not the design. Designing a new site is the fun part. Mapping every old URL to a new one so that no link in the wild ever breaks, and confirming each redirect actually works, is the unglamorous essential work that most rebuilds skip and then regret. Google Search Console's coverage report is your best friend for catching the ones that slipped through.
Use the right Claude product for the right phase. Claude Design is built for the visual, exploratory, what-could-this-look-like work. The chat interface running Claude Opus is built for code, errors, and iterative debugging. I split this rebuild cleanly between the two and would do it the same way again.
Cloudflare Pages is genuinely free, and that word is doing real work in this sentence. Not free with a paid tier waiting to bite you the moment your traffic grows. Not free as a loss-leader for a more expensive product. Genuinely free, for static sites of any size most small businesses will ever build, with no realistic ceiling I expect to hit. The €28 a month I was paying Squarespace becomes €336 a year back into my business, every year, indefinitely. Over five years that's €1,680 that no longer leaves my account for hosting a site that, in design and content terms, I now own outright.
Which brings me to the part that matters more than the cost. Every file my site is built from now lives on my machine. Every page, every component, every line of CSS, every redirect rule, every image. The whole site is a folder I can copy onto a USB stick. If Cloudflare went down tomorrow, or hiked their prices to something unreasonable, or made a policy change I disagreed with, I could move the entire site to any static host on the planet in an afternoon. Netlify, GitHub Pages, Vercel, my own server: any of them would serve the same files in the same way. The site is mine in the sense that ownership of files normally implies, which is a different thing from owning a Squarespace account that lets me edit content the platform stores.
That distinction was never visible to me while I was on Squarespace, because the platform did its job and I had no reason to think about what would happen if it stopped. The Squarespace export I downloaded as part of this migration is a Wordpress-compatible XML file that contains my old blog post text and a list of image URLs that still point at Squarespace's servers. It does not contain my design, my custom code, my page structures, my forms, my members area, my SEO redirects, or my settings. If Squarespace had gone down before I migrated, I would have been left with a partial archive of my own writing and would have needed to rebuild everything else from scratch. With the new setup, the rebuild scenario looks completely different. I would change a DNS record and the site would be back up. That's what I mean by future-proofing. Not preparing for a particular disaster, but removing the dependency that would make any disaster expensive.
I've been moving away from other platforms that don't fit my values too. I wrote about switching from Google Analytics to Simple Analytics earlier this year, and the reasoning is similar. The thread running through these decisions is wanting to depend on fewer things I cannot replace.
Allow more time than you think you need for the deployment. Block out three or four days, not one. Most of it won't be productive in the visible-progress sense. You'll be on hold with your own infrastructure, watching curl traces, deleting browser caches, redeploying, watching it break in a new way. This is normal. It is also where the actual work is.
Turn on file extensions in your operating system before you start renaming anything. If you're on Windows, open Explorer, View, Show, tick "File name extensions." If I'd done this on day three I'd have saved myself an hour.
Don't run project-wide find-and-replace on a working codebase without checking the regex setting first. Twice now I've recommended this to people and twice now they've checked the regex toggle is off, made a single replacement, deployed, and been fine. The third time, the toggle was on, and we spent a morning rebuilding thirty-seven files. Verify the toggle.
Save the work. I kept the original Squarespace export. I kept screenshots of the old site. I kept the deployment logs from every Cloudflare rebuild, including the broken ones, because the broken ones turn out to contain most of the lessons. If you're curious about what else this approach has unlocked, I built a paid product the same way: same pattern of human direction and AI execution, same lesson about where the value sits.
What this actually means
The breathless version of this story is that AI built me a website in two days. The fuller version is that Claude Design helped me build a website in two days, and then Claude Opus and I spent another three days deploying it properly, and the two days were the part Claude Design was best at, and the three days were the part Claude Opus and I were best at together, and neither phase would have produced the result on its own.
I think that's a more useful frame for where we actually are with this technology. The floor has risen. Competent generic output is now extraordinarily cheap. The ceiling has risen further. Strong taste paired with AI can produce work that didn't used to be available to a one-person business at any price. And the gap between those two outcomes is almost entirely about whether the human in the loop has the patience, the attention, and the technical literacy to steward the work through the parts where the AI alone produces something that almost works.
The site is live. It's mine. The journey to get it live taught me as much as the design phase did, and I'd argue most of the durable lessons came from the second phase, not the first. If you're going to do something like this, expect the same. Plan for the deployment to be its own project, with its own learning curve. The fact that the first half went quickly doesn't mean the second half will.
If you're thinking about leaving Squarespace or another platform and want a steady hand on the migration, get in touch. This is exactly the kind of work I help clients with.