The point isn't the stack. The point is the loop.
And the loop starts with taste.
1. Start with the inspirations
I love Linear's opinionated simplicity. Anchor this as the starting point.
The principle: name the one thing each site does best. Borrow that.
The six that made the cut, and what I wanted from each:
- Linear — the feel: restraint, one accent, clean type.
- Rauno Freiberg — interactive components on the page, not screenshots.
- Maggie Appleton — topic pages instead of tag clouds; epistemic tone.
- Stripe — monospace for technical metadata.
- Vercel — dense but breathing — informationally rich without feeling cluttered.
- Josh Comeau — author presence and inline interactivity.
2. One prompt set the whole system
I didn't design a pipeline. I made three decisions in one prompt:
That one prompt did three jobs in one sentence: it pinned the design system to Linear, locked the build order (shell, then pages), and kept content separate from the UI so I could move it to Obsidian later.
3. How I prompt — and why critique drives design
The pattern that repeats: I don't tell Claude what to change. I describe what feels off in plain language and let Claude propose the fix.
Three prompts did most of the heavy lifting.
Each one describes a feeling that's off, not a specific change. Claude proposed the fix; I argued with it; only then did code get written.
4. How I critiqued — playing VC, product leaders, designer
After every major route, I stepped out of build mode and asked Claude to put on three hats:
Three lenses surfaced different things. The VC kept asking what I actually do. The product leader flagged where the site looked thin. The designer caught taste-and-craft gaps I couldn't see myself.
The point wasn't the critique — it was what I cut after reading it. Run the loop after each ship, not just at the end. That's the part that kept drift down.
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:
01 · Design-system shell
Tokens in globals.css, typed primitives (Container, Heading, Text, Button), a layout with header + footer. No pages yet.
02 · Landing
One page, end-to-end, before anything else. Forces the first version of most MDX components into existence.
03 · PM Skills port
The most content-dense surface — ported from an existing app, re-skinned into the design system. Surfaced the ContentSource pattern.
04 · First-Principle coach
The one interactive app. Validated that the design system holds up when something is actually interactive, not static.
05 · Workflow build logs
Meta-content about the build itself — where this post lives.
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.
Tools I leaned on
| Tool | Used for | Why |
|---|---|---|
| Claude Code | Building the site end-to-end | The agent that respects context and doesn't drift |
| Claude Cowork | Research + markdown context + decks | Where long-form thinking lives |
| Perplexity | Quick research + fact-checking | Faster than Claude when I just need an answer |
| Obsidian | The editing surface for everything on this site | Backlinks + vault graph make writing feel like thinking |
| Linear design tokens | Visual system | The benchmark for AI-era taste |
| getdesign.md | Linear's tokens in machine-readable form | The single biggest reason the design system landed cleanly on day one |
| Vercel / Netlify | Deploy | Both work; Claude ships to Vercel cleaner |