Own Your Stack, Part 1: The Why

In Part 0, I laid out the problem: I build things constantly that nobody sees, and the publishing pipeline is the bottleneck. The decision to migrate off Squarespace was the first step. This post covers what came next: the technology selection, the cost analysis, and the bootstrap phase where Claude Code and I stood up the project together.

The primary takeaway from this exercise was that AI and LLMs are no substitute for domain knowledge and experience. This leg of the journey took about 6 hours. Here’s how it went.

The Napkin Math

Before writing a single line of code, I spent time in Claude’s deep research mode working through the full decision space: what does the complete stack look like, what does it cost, and what are the tradeoffs for every component?

Scheduling and payments are deferred, not abandoned. When there’s a demonstrable need, I’ll handle them (Cal.com for scheduling, any number of payment processors for invoicing). The point is to stop paying for them while they’re unused.

Cloudflare Pages won over AWS CloudFront (Route 53 costs), Netlify (credit-based pricing that pauses your site), Firebase (bandwidth caps), and GitHub Pages (requires public repos on free tier). No bandwidth limits, no credit card required, genuinely zero cost with the fewest constraints.

Choosing Hugo (and Why Not the Others)

Hugo won on three points: zero runtime dependencies (it’s a single Go binary), sub-second builds, and the largest community of any static site generator. For a content-focused site with no interactive components, the JavaScript-based alternatives (Eleventy, Astro) add dependency management overhead for zero benefit. Zola was the closest competitor (also a single binary, Rust-based) but has a much smaller ecosystem.

The Docker-based build means I don’t even need Hugo installed locally:

docker run --rm -v "$PWD:/src" hugomods/hugo:latest hugo --gc --minify

The entire site builds in under a second. My Squarespace site took longer to load than this takes to generate.

The Bootstrap: Standing Up a Project with Claude Code

Here’s where things get interesting. I didn’t just ask Claude to “build me a website.” I started a structured collaboration: I brought design documents and an implementation plan that I’d refined through three rounds of deep research, and we worked through them together.

The first session covered project bootstrap: initializing the repo, setting up a skills library (reusable instruction sets that tell Claude Code how to handle specific tasks like writing ADRs or scaffolding blog posts), migrating all content from the Squarespace site mirror, and evaluating theme options.

I had Claude connect to my self-hosted Sourcegraph instance via my MCP server to pull skills from my existing Django project. With MCP, Claude can reach into your infrastructure, search your repos, and pull context from tools you already use. The skills I’d built for a different project became the foundation for this one.

Content migration was straightforward: I’d already run an HTTrack clone of the Squarespace site, so Claude used BeautifulSoup to extract text, map images, and generate Hugo-compatible markdown with the full frontmatter schema. Three blog posts, a services page, a contact page, all converted in one pass. Honestly overkill (I could have just clicked “save as” in a browser), but I wanted to see how Claude would approach something I know inside out. Baseline evaluation before trusting it with the hard parts.

The Theme Trap (and Why “Easy” Tools Fight Back)

This is the part of the story where I learned something I didn’t expect.

The research pointed to PaperMod, the most popular Hugo theme, as a safe choice for the frontend. It seemed like an obvious choice: config-driven customization, zero CSS build pipeline, great blog support. We installed it, configured it, migrated the content, and built the site. It worked. And it looked nothing like my actual website.

The problem wasn’t PaperMod’s quality. It was a fundamental architectural mismatch. PaperMod wraps all page content in a 720px centered column. My Squarespace site uses full-width sections: each section of the page owns the entire viewport width, with content constrained inside each section independently. You can’t CSS-override your way out of that. The layout model is baked into the theme’s HTML structure.

So we tried Congo, the Tailwind-based theme. Surely a modern Tailwind theme could handle full-width sections? Nope. Congo’s Tailwind CSS is pre-compiled with only its own utility classes. Custom classes didn’t exist in the output, the container prevented full-bleed sections, and the dark mode infrastructure kept overriding my brand colors.

Two themes. Both well-built. Both architecturally incompatible with a simple requirement: full-width sections with alternating image and text layout.

The lesson is twofold. First: if you don’t plan properly, you will waste time on execution. This is universal advice that everyone needs to hear. It’s the 21st century tech version of “measure twice, cut once” and “failure to plan is planning to fail.” A half hour of intentional frontend pattern analysis on the Squarespace source (identifying the full-width section model, the alternating layout directions, the viewport-spanning backgrounds) would have given a deep research context everything it needed to surface the architectural incompatibility in about fifteen minutes. Instead, I skipped that step and spent two hours on trial and error that told me exactly what structured analysis would have revealed up front.

Second, and more valuable: this is an AI-native workflow discovery. The right move was to build a dedicated skill for decomposing a source site into its frontend patterns and layout requirements before evaluating themes or writing any code. That skill doesn’t just solve this problem; it’s reusable for any future migration or theme evaluation. I always build things that can be adapted, and the two hours I spent learning this lesson is worth the cost the first time. It’s not worth paying twice. We ultimately wrote a custom Hugo theme (plain HTML and CSS, no framework) and it took less effort than either theme evaluation cycle.

What Made It Work (and What Didn’t)

What made it work wasn’t Claude. It was me. Recognizing the patterns in the source CSS that mattered. Spotting when the assistant was burning tokens re-grepping the same selectors it had already read. Making Claude explain what it was doing and why before letting it write code. Correcting its approach when it diverged from how I would have done it myself.

This is another AI-native workflow takeaway: if you are an expert at something and you have opinions about how it should be done, you need to mentor your AI assistant. Don’t just use it; TEACH it. The SVG clip-paths, the brand colors in HSL, the pill-shaped buttons with border-radius: 300px: Claude never found any of these on its own. I recognized them in the source and pointed Claude at them. I knew where to look in the CSS while Claude was writing ad hoc Python scripts with BeautifulSoup. But here’s the thing: every time I corrected it, Claude did it perfectly from that point forward. The friction disappeared. It turns out that Claude CAN do judgment; it just needs to be taught how to apply that judgment within a narrow scope.

The things that didn’t work well: I had to course-correct Claude multiple times when it added features I didn’t ask for while neglecting the two things I explicitly said I cared about (the brand colors and the alternating left/right section layout). Claude Code’s memory feature helped here; corrections stuck immediately and carried forward.

Both observations drive the same takeaway: intentionality is everything. The practitioners who will get the most out of AI-assisted development are the ones who build skills: reusable instruction sets that clearly communicate intent, style, and expectations to the LLM. Without that, every session starts from zero. With it, you get predictable, consistent outcomes that match how you actually work. This post itself is the proof: it was generated for me based on the content-transform skill, which I taught to mimic my writing style and voice. I edited it for final release, but it was a 15 minute editing job instead of an hour-long writeup from scratch.

The Series

• Part 0: The What: Why I built a publishing pipeline instead of just writing more posts on the platform I already had.
• Part 1: The Why (you’re here): Technology selection, the napkin math, standing up the project with Claude Code, and the theme trap that reminded me to plan before I build, even when I’m excited about building.
• Part 2: The How: Custom theme implementation, the three-color section system, contact form integration, and deploying to Cloudflare Pages.
• Part 3: Baseline SEO: A 30-year technologist who’s never done SEO uses Claude to learn the basics and optimize a Hugo static site.
• Part 4: Content SEO: Making every page worth indexing. Tag page enrichment, internal linking, and the SEO that actually matters for a small site.
• Companion: DNS Cutover: The full DNS migration to Cloudflare, and why AI-assisted planning is no substitute for infrastructure review.
• Companion: DNS Cutover: The full DNS migration to Cloudflare, and why AI-assisted planning is no substitute for infrastructure review.

The Clouditect helps businesses simplify their technology. If you’re paying too much for too little, or struggling to make your tech stack work for you instead of against you, let’s talk.