Leaving Squarespace, Part 1: Why I Pulled the Plug
Series note: this is Part 1 of 6. Each part stands alone, but together they’re the whole story of the move.
Where this started
For years, all of this lived on Squarespace: the blog, the podcast pages, the domains. And honestly, it worked. It’s a good product. You don’t have to think about hosting, certificates, or whether your images are going to load. That’s the whole pitch, and they deliver on it.
But I kept bumping into the same wall. It was their house, not mine. My content, my domains, my audience, all sitting inside a system where the rules, the prices, and the limits were set by someone else.
The irony is that Squarespace’s templates, the thing they’re famous for, became my problem. They looked great, but keeping formatting consistent across posts was cumbersome. I ended up running half my process offline, manually massaging content before it ever touched the editor. And no matter what I did, I could never get the desktop and mobile versions to behave the way I expected. For a platform whose whole pitch is “we handle the presentation,” I was doing a lot of presentation work.
The three things that pushed me over
1. Cost that only goes one direction. Subscriptions are easy to start and easy to forget. But when I added it up (the site plan, plus the pieces I was paying for around it) I was spending real money every year to rent a setup I could run myself for basically nothing.
The kicker: a chunk of what I was paying for was commerce tooling. Storefronts, checkout, inventory. I wasn’t selling anything. Once I noticed I was paying for a store I’d never open, the whole cost structure demanded a second look.
2. Lock-in. This is the one that bothers me as an engineer. On Squarespace, my posts weren’t really files I owned; they were rows in their database, rendered by their templates. Moving meant extracting everything by hand. The longer I stayed, the more expensive leaving would get. That’s not an accident, that’s the business model.
3. I wanted to learn by doing. I write about Azure, Veeam, Kubernetes: infrastructure. There was something a little funny about running all of it on a platform where I never touched the infrastructure. Rebuilding it myself meant I’d actually understand every layer, and could write about it from experience instead of theory.
If I’m honest, it was mostly curiosity with a healthy dose of stubbornness. I spend my days talking about infrastructure, and there was something backwards about my own corner of the internet being the one place I never touched the plumbing.
But there was a second thread pulling at me: AI. I’ve been increasingly curious about where AI actually fits into our lives, enough that Greg Carl and I started a podcast, Not a Bot, to dig into exactly that intersection of AI and humans. And I have real concerns: the billionaires steering it, the data center footprint, the creative work being scraped without consent. But the benefits to humanity are hard to deny. I decided the only honest position was to get my hands on the tool and learn firsthand how it impacts my life. The test I set for it: does it save me time without taking my time away? This migration became that experiment. An AI did the heavy lifting on this move, and this series is partly the story of how that went.
The setup that clicked for me: I describe the vision, and the AI is a coworker (literally, that’s how I think of it) who executes on it. And because every step gets explained as it happens, I’m learning the whole way. Some things it hands back to me to do manually, and honestly, that’s part of the lesson too. I learn by doing, and this is doing.
What “owning it” actually means to me
My bar was simple. If a vendor disappeared tomorrow, could I stand the whole thing back up from files I control? On Squarespace, the answer was no. That’s the test that started this whole project.
So the goal became: a content network I fully own, that costs about nothing to run, where every piece is a plain file or an open service I could swap out. Three properties (West Coast IT Hipster, The SE Journey, and Not a Bot) under one roof, with their own identities but one backend.
If you’re an SE, a sysadmin, or anyone who’s ever felt like a renter on your own website, this series is for you. Over the next five parts I’ll walk through the stack I chose, how years of content made the move, self-hosting a podcast feed, automating the publishing, and the domain dance that kept my email alive. On the other side of it all, the answer to that vendor-vanishes question is finally yes, and it cost almost nothing but curiosity.
Next up, Part 2: the stack. What I picked (Astro, Cloudflare, R2, Supabase) and why each one earned its spot.