How I built this site

The point isn't the stack. The point is the loop.

And the loop starts with taste.

1. Study 5 sites deeply, not 50 casually

Before I wrote a single prompt, I picked a small set of sites and studied them the way a designer would study a painting. Not a Pinterest mood board of 50 screenshots. Five or six sites I'd take apart, open in DevTools, and read the CSS of.

The principle: name the one thing each site does best. Borrow that. Don't copy the whole aesthetic. Taste is transferable; aesthetics aren't.

How to do this yourself. Open the site in your browser, not on Pinterest. Turn off the images. Now look at navigation, typography, spacing, and motion separately. What's the one thing you couldn't live without if you shipped a version of this site tomorrow? That's the thing to steal. Everything else is noise.

2. How I prompt — and why critique drives design

The non-obvious pattern after 20+ sessions on this site: state the gap → describe what "better" looks like → ask for the shape before the code. Plan Mode before Build Mode, always. The critique is rooted in what I can see, not in implementation.

Three prompts did most of the heavy lifting.

Every one of those prompts describes a feeling that's off. None of them says what to change. Claude proposed the shape; I argued with it in Plan Mode; only then did code get written.

Ship fast, look hard, push back. That's the loop underneath the loop.

3. The design system pipeline

Consistency across a dozen routes isn't discipline. It's plumbing.

The recipe: every value that might change lives in a token. Every component reads the token. No hex past globals.css. New components extend a primitive (Button variant="pill"), never fork one. This is why 12 routes feel like one site — not because I'm careful, but because the system is boring enough that drift is hard.

4. Where the content lives

The biggest mistake I made on this site wasn't technical. It was not deciding, early, where writing should live.

Writing felt natural in Obsidian — backlinks, vault graph, outlines, the whole thinking-surface. But the site renders from .md files in the repo's /content directory. Every time I wanted to update a paragraph I hit the same question: where is this the source of truth right now? Twice I lost edits by saving on the wrong side.

The fix is a one-way bridge.

Underneath the bridge, there's one architectural bet worth calling out: every page reads content through a single interface (content.getX()). No page reads MDX directly. Today that resolves to files on disk. Tomorrow it could be a CMS, a database, or a Git-backed notes system, and no page needs to change. Put one boring interface between pages and content, and your storage gets to rot and be replaced.

5. Ship cadence — one page at a time

The temptation is to prompt "build me the whole site." The result is always 12 half-done routes. I shipped in this order instead:

1. 01

   01 · Design-system shell

   Tokens in globals.css, typed primitives (Container, Heading, Text, Button), a layout with header + footer. No pages yet.

2. 02

   02 · Landing

   One page, end-to-end, before anything else. Forces the first version of most MDX components into existence.

3. 03

   03 · PM Skills port

   The most content-dense surface — ported from an existing app, re-skinned into the design system. Surfaced the ContentSource pattern.

4. 04

   04 · First-Principle coach

   The one interactive app. Validated that the design system holds up when something is actually interactive, not static.

5. 05

   05 · Workflow build logs

   Meta-content about the build itself — where this post lives.

6. 06

   06 · About hub + problems

   The last pages to ship, because by then every component they needed already existed.

Principle: each page exposes the missing component before the next one gets planned. If you batch, you build 12 versions of "almost right" instead of one version of right.

6. If you're starting today

• 01

  Taste before prompts

  Pick 5 sites. Open them in the browser, not on Pinterest. Name the one thing each does best. That's your palette.
• 02

  Prompt the shape, not the code

  Describe what "better" looks like. Argue structure in Plan Mode. Claude fills in the implementation.
• 03

  Tokens before components

  Any value you'd describe with a word — brand color, body font, base radius — lives as a token. Components read; they never hardcode.
• 04

  Bridge your writing and your code

  One script. Pick a source of truth. The other side is a mirror. Stop asking "where do I edit this?"

Your reasoning is still the moat. AI collapses the time from idea to prototype. It doesn't decide what to build or what "good" means. That part is still yours.

Tools I leaned on