Building This Portfolio

Goal

I wanted one place to show my lab work: a site that’s fast, easy to add to, fully customizable, and built by me rather than assembled from a theme. It also had to be free to run.

Choosing the stack

I compared five approaches before writing any code:

Option	Why I didn’t pick it (or did)
Plain HTML/CSS	Total control, but every new project would mean copy-pasting headers and layouts
Hugo	Very fast, but its Go templating makes a custom design harder
Next.js / SvelteKit	Built for full applications; more moving parts than a portfolio needs
WordPress / Ghost	Quick to look polished, but least “from scratch,” and one more server to patch
Astro + Tailwind + MDX	Built for content sites, ships plain HTML, and every project is just a file

How it works

• Each project is one MDX file with structured frontmatter: title, status, date, tags, stack, and hardware.
• A typed schema checks every file. If I misspell a field or forget a summary, the build fails with a clear error instead of publishing a broken page.
• Templates do the rest. One template generates every project page; the homepage, project list, and the patch panel all read from the same collection.
• The theme comes from networking hardware. Project status uses switch-port lights (steady green for completed, pulsing amber for in progress), and the homepage is a patch panel where each port is a project.

Problems I hit

• PowerShell blocked npm. Windows’ default script execution policy refused to run npm’s PowerShell wrapper. Setting the policy to RemoteSigned for my user account fixed it without loosening anything machine-wide.
• OneDrive and node_modules don’t mix. My Desktop syncs to OneDrive, and a JavaScript project has tens of thousands of small files. I moved the project to a local, unsynced folder; GitHub is the backup.
• Publishing a lab safely. My lab notes are full of internal IP addresses, hostnames, and account names. Everything on this site is reviewed and scrubbed first, including screenshots.

Working with AI

I used Claude as a pair-programmer for this site: talking through stack options, debugging setup errors, and drafting the first versions of these write-ups from my own lab notes. I reviewed, tested, and edited everything before publishing.

What I learned

• A content schema is worth the five minutes it takes. It turns typos into build errors.
• Start with the content model, then design. The pages fell out of the data.
• Operational security applies to a portfolio too. Being specific about what I built doesn’t require publishing how to reach it.

Next steps

• Deploy to Cloudflare Pages with automatic builds on every push
• Add a custom domain
• Tag filtering on the project list and site search with Pagefind
• Screenshots and diagrams for every project