Building My Portfolio Into a Publishing System
I started this repo because I wanted a place to publish projects, then kept rebuilding it until it could actually support the kind of technical writing and project history I wanted to put on it.
This series is a short history of that evolution: from a basic static site, to a more structured Gatsby content system, to notebooks and plugin work, to maintenance fights, to the recent blob-storage, editorial tooling, and LLM-assisted writing workflow.
The series is dated from the repo’s first commit in 2019, but the story itself runs through the more recent editorial and LLM work in 2026.
What to expect
Each article focuses on one problem arc rather than trying to retell the entire git history.
- From Static Site to Publishing System — how the site started, why I outgrew the first version, and what I learned from the migration. ~6 min read
- Inventing a Content Model for Real Projects — tags, series, clusters, and stronger page-generation rules. ~6 min read
- Publishing Dense Technical Work Without Watering It Down — notebooks, embeds, and richer technical writeups. ~6 min read
- Owning the Seams: Plugin Forks and Toolchain Drift — dependency breakage, vendoring, and maintenance reality. ~7 min read
- Turning the Site into a Portfolio Editorial Machine — blob storage, Obsidian support, and the repo becoming an authoring workbench. ~6 min read
- LLM Tooling for Portfolio Writing — repo-history synthesis, quality reporting, and turning a vague editorial backlog into concrete next steps. ~7 min read
The through-line is pretty simple: every time the tooling got in the way of the kind of work I wanted to publish, I either changed the workflow or pulled more of the system into the repo so I could control it.
If you read the whole series, the takeaway I want to leave is that this portfolio is not just a gallery of finished projects. It is also a long-running exercise in building the system that can hold the work without flattening it.
From Static Site to Publishing System
I started this repo because I wanted a place to publish projects. That was the whole brief. Built the first version of the portfolio, pushed past the starter-template stage, and turned an initial Zola site into the beginning of a custom publishing system.
Inventing a Content Model for Real Projects
Once I moved to Gatsby, the problem stopped being “how do I have a site?” and became “how do I structure a site that can actually hold the work I want to publish?” Built a content-driven portfolio model with tags, series, clusters, page-generation rules, and stronger TypeScript-checked structure.
Publishing Dense Technical Work Without Watering It Down
At some point I realized that plain markdown was not visually or structurally distinct enough for the kind of work I wanted to publish. Expanded the site into a denser technical publishing tool with notebook embedding, richer article framing, and better support for project artifacts that did not fit clean blog-post shapes.
Owning the Seams: Plugin Forks and Toolchain Drift
The least glamorous part of this repo is probably the most representative part. Recovered the site from toolchain drift by pinning dependencies, vendoring unstable pieces, and treating maintenance work as part of the product instead of background cleanup.
Turning the Site into a Portfolio Editorial Machine
The most recent era of this repo is where a bunch of half-formed ideas finally snapped together. Expanded the repo into an editorial workbench with blob-backed media logistics, Obsidian-friendly authoring, and LLM-driven tooling for prioritizing and drafting portfolio content.
LLM Tooling for Portfolio Writing
Built LLM-backed editorial tooling that turns repo history, notes, and existing markdown into concrete portfolio-writing workflows instead of generic text generation.
The benefits of trad-coding
After my tokens ran out I realized how valuable hand-coding is