Production Portfolio Website

Context

I needed a production-ready portfolio that could be maintained as a real engineering project, not a one-off static site. The site you’re reading is the artifact, so every claim it makes about engineering discipline is checkable against the repository it ships from.

Content architecture

Projects and writing are Zod-validated Astro Content Collections rather than hand-authored pages. Invalid frontmatter fails the type check and the build, so a malformed entry can’t reach production. Case-study pages, post pages, tag pages, and the RSS feed are all generated from those two collections, which means adding content is writing one Markdown file and nothing else.

Performance as a gate, not a goal

The deploy runs a Lighthouse CI budget before publishing, and a failing score blocks the release rather than filing a warning somewhere:

See a passing production run. The script budget is the one that shapes decisions most: it rules out shipping a framework to render text, so the site’s client-side behavior stays framework-free and narrowly scoped.

Delivery

Pull requests run asset generation, lint, format check, type check, and a full production build. Pushes to master add semantic-release, which computes the version from Conventional Commits, updates the changelog, tags, and publishes to GitHub Pages with no release PR to approve.

Outcome

The site is both a public portfolio and a maintainable technical baseline for future projects and writing.