Leaving Squarespace, Part 2: Choosing the Stack
Part 2 of 6.
The guiding rule: boring, free, and replaceable
When you leave an all-in-one platform, the temptation is to recreate it with one big shiny replacement. I went the other way. I wanted each piece to do one job, to sit on a free tier, and to be swappable if it ever let me down. If any single vendor here vanished, I should be able to replace just that box, not start over.
For me it comes down to two things: reliability, and whether I can manage it without it becoming a second job. Complexity doesn’t equal good. If you need a master’s degree in a product just to run it, the product probably isn’t intuitive. You adopt technology to get a result: do a task, serve a function. The function should never be the technology itself. If the tool becomes the work, you might as well have built it yourself.
The site: Astro (static)
The blog and podcast pages are built with Astro, output as a fully static site: plain HTML and CSS, no server running my code. Static means it’s fast, nearly impossible to take down, and cheap to host anywhere. My posts are Markdown files in a Git repo. That alone solves the lock-in problem from Part 1: the content is files I own.
Hosting: Cloudflare Pages
Cloudflare Pages hosts the built site on their global network for free, and rebuilds automatically every time I push a change to GitHub. It also gives me DNS, SSL, analytics, and little edge functions in the same place, which mattered later when I needed some routing tricks (Part 6).
Honestly, I didn’t run a big bake-off against Netlify or Vercel or a box in the homelab. Cloudflare kept coming up in my community, people I trust already use it, and it came recommended when I started working through this migration with Claude. Sometimes a recommendation from folks who run this stuff daily beats a weekend of comparison charts.
Big files: Cloudflare R2
Podcast episodes and blog images don’t belong in a Git repo; they’re big and binary. They live in Cloudflare R2, object storage that’s S3-compatible but with free egress. That last part is the quiet hero: most storage charges you every time someone downloads a file, which is exactly what a podcast does all day. R2 doesn’t. Served from media.thebetasociety.com, it’s effectively free hosting for the heavy stuff.
The dynamic bits: Supabase
Not everything is a static file. The Not a Bot podcast has companion articles that get drafted and approved in a separate app, and the site reads the published ones from Supabase (a hosted Postgres with an API). The site pulls those in at build time. It’s the one “database” in the whole setup, and it’s only there because that property genuinely needs it.
That one property earns a real backend because of an idea I got clued into: a Brain. One central repo for everything we gather and create. Greg and I work at a distance, and the Brain gives us an easy way to work and communicate without me managing the tech: no shuffling files, no fixing availability, no chasing the latest copy. Everything else stays flat files because nothing else needs more.
What I deliberately did NOT add
No CMS. No server framework. No container to babysit. No build step more complicated than “turn Markdown into HTML.” Every piece I left out is a piece that can’t break at 2am. For an ex-admin, that restraint felt like the whole point.
The trade-off I’m most at peace with is the simplicity. The one that worried me: I was afraid a site this stripped-down would be hard to keep appealing enough for people to visit. A site should be easy to consume. So far the fear hasn’t held up; fast and readable turns out to be exactly what easy-to-consume looks like.
Next up, Part 3: actually moving the content. Crawling years of posts out of Squarespace, fixing every link, and hauling 144 media files to R2.