I built this site in an afternoon. Most of the time wasn’t typing code — it was making decisions and refusing to make others. Personal projects die in scope creep more than they die in technical difficulty, so the discipline was almost entirely about what not to build.
Five decisions that mattered, with the reasoning that actually drove them.
1. Mixed personal site, not a portfolio
The default move when a developer wants “a website” is the portfolio: three case studies, a hire-me section, a clean grid. I chose the opposite — a mixed site that holds work, writing, TTRPG mechanics, recipes, half-formed notes, whatever. The portfolio version is a worse version of LinkedIn unless I’m actively job hunting; the mixed version gives me a reason to touch the site weekly because something is always growing somewhere on it.
The risk of the mixed approach is that it can feel scattered. The mitigation: section structure clear enough that someone landing on /work doesn’t accidentally see D&D content. Sections do the segmentation; the navigation does the unification.
2. “TTRPGs,” not “D&D”
The section that hosts my game design content is called TTRPGs, not D&D, even though most of the content right now is D&D-specific. The reason isn’t precision — it’s preventing pigeonholing. “D&D guy” is a smaller frame than “person who designs game mechanics.” The label sets the ceiling on what can credibly live there later.
A small naming decision, made deliberately, that locks in optionality for free.
3. Notes vs. Writing — two different posting cadences
I split short-form and long-form into separate sections (/notes and /writing) instead of one blog. Same reason behind both: psychological. A blog implies polish. A notes section implies I can post a half-formed thought and move on. A writing section implies I’m working on something that took effort.
Without the split, everything tends to drift toward the standard of the most polished thing I’ve ever posted, and I post less. With the split, the bar adjusts to the section.
4. Ship the skeleton, fill content second
The first deploy of this site had no real content — just the structure, the design language, and stub pages. Live on the domain in an afternoon, before any of it was good. This sounds backwards, but the alternative is worse: most personal sites die because the author keeps trying to make the homepage perfect before showing it to anyone.
A live site you can iterate on is infinitely more durable than a polished one you’re afraid to ship. Lowering the stakes of the first version is the actual unlock.
5. Notion as the CMS for recipes
The recipe section pulls from a Notion database I’ve maintained for years. This is a mild architectural decision but it has a strong scope implication: I’m not building a recipe editor. I never will. The day a recipe page on this site is “wrong” is the day I update Notion and trigger a rebuild. The site is read-only for me; Notion is where I author. That asymmetry keeps the codebase small and means recipes get updated because they’re easy to update, not because I committed to maintaining a custom admin UI.
The tradeoff: rebuilds for recipe edits are slow (a couple minutes). For my actual usage pattern, that’s fine. I’d revisit the call if I ever started cooking professionally.
None of these are universal principles — they’re choices that fit this project. But the meta-pattern is the same one I rely on at work: the most important decisions are the ones about what not to do. Scope is the lever; everything else is execution.