How This Site Gets Built — From Squarespace to Static, Git-Driven, AI-Assisted

I used to run my personal site on Squarespace at moffcorp.co.uk. It worked fine. Drag-and-drop editor, managed hosting, SSL handled for me. But it never quite fit. I’m an infrastructure engineer — I wanted to own the pipeline, not rent a page builder.

So I rebuilt the whole thing. New domain (moffcorplabs.com), new stack, new workflow. This post covers how it all works.

Why Leave Squarespace?

Nothing was wrong with Squarespace. It’s a solid product for most people. But for me it was a mismatch:

• No version control. Every change was a live edit with no history, no rollback, no branching.
• No CI/CD. I couldn’t test changes before they went live.
• No code ownership. The site was locked into their platform. If I wanted to move, I’d be starting over anyway.
• Cost. I was paying a monthly subscription for what could be a static site hosted for free.

I wanted something I could treat like infrastructure — versioned, reviewed, automated, and deployable on my terms.

The Stack

The site is built with:

• Astro — A static site generator that ships zero JavaScript by default. Pages are .astro components with markdown for blog content.
• Tailwind CSS — Utility-first CSS. The entire site uses a custom terminal-inspired theme with no external UI library.
• Markdown — Blog posts are plain .md files with YAML frontmatter. Astro’s content collections handle schema validation and rendering.
• GitHub Pages — Free static hosting with custom domain support and automatic TLS.

No database, no CMS, no server-side runtime. The whole site compiles to static HTML and CSS.

Two-Repo Deployment Model

The site uses a split-repo approach:

Repo	Purpose
Website_Dev	Source code, Astro project, blog posts, CI/CD pipeline
Website_Prod	Compiled static output served by GitHub Pages

The dev repo is the workspace. All changes happen here — new posts, layout tweaks, component work. The prod repo only ever receives compiled output. It never gets edited directly.

This separation gives a few benefits:

• Clean production history. Every commit in Website_Prod is a deployment, not a mix of drafts and typo fixes.
• Independent access control. The prod repo can be locked down with branch protection rules independent of the dev workflow.
• Simple rollback. Reverting a deployment is just reverting a commit in prod — no rebuild required.

CI/CD Pipeline

A GitHub Actions workflow in Website_Dev handles the full build-and-deploy cycle:

1. Trigger — Push to main or manual dispatch.
2. Build — Checkout the source, install dependencies (npm ci), and run the Astro build (npm run build).
3. Deploy — Push the compiled ./dist output to Website_Prod.

The workflow uses pinned action versions by SHA digest, runs with least-privilege permissions, and uses concurrency controls to prevent overlapping deployments.

The branch workflow in Website_Dev follows the same pattern as my infrastructure repos: never commit to main directly. All work goes through feature branches (feat/, fix/, docs/, chore/) with PRs and squash merges.

TLS and DNS

The domain moffcorplabs.com is managed through Cloudflare. GitHub Pages handles TLS certificate provisioning automatically once the custom domain is configured. DNS points to GitHub’s Pages servers, and HTTPS is enforced at both the Cloudflare and GitHub layers.

No manual certificate management. No renewal scripts. It just works.

Claude Code as a Design Partner

Here’s the part that might raise eyebrows: this entire site was designed and built using Claude Code as a development partner.

I’m not a frontend developer. I can write CSS when I have to, but I don’t enjoy it, and I’m not fast at it. Claude Code changed the equation — instead of fighting with layout and styling, I could describe what I wanted and iterate in real time.

The workflow looked like this:

• I’d describe a layout or component in plain language.
• Claude Code would generate the Astro component with Tailwind classes.
• I’d preview it locally, give feedback, and iterate.
• Once it looked right, we’d commit, PR, and merge.

Claude Code handled everything from the terminal theme design, to the animated hero text, to the blog post rendering pipeline and GitHub Actions workflows.

Closing Thoughts

Moving from Squarespace to a Git-driven static site was one of those changes that felt disproportionately satisfying. The site is faster, cheaper to run, and I actually understand every piece of it.

More importantly, it fits how I work. Every change is tracked. Every deployment is reproducible. And when something breaks, I can git log my way to the answer instead of submitting a support ticket.

If you’re an infrastructure person running a personal site on a managed platform — consider whether you’re solving the right problem. You already know how to build pipelines. You already know Git. The gap is usually just the frontend, and tools like Claude Code are closing that gap fast.