Overview
- Project
- Personal portfolio and blog
- Focus
- Publishing / Frontend / Content architecture
- Stack
- Next.js / React / MDX
- Approach
- Local content, pre-rendered pages
My personal site has two main jobs: give my work a home and make it easy to publish what I learn. Its publishing setup should fit the way I actually write.
The previous version used a full CMS. For this iteration, I moved articles and case studies into local Markdown files, with MDX for the occasional interactive component. The aim was to reduce the infrastructure behind a small, single-author site while keeping control over its design and content.
What the CMS supported
The earlier site used Payload with PostgreSQL, a rich-text editor, draft publishing, and media uploads backed by blob storage. Blog posts and projects were structured collections, with hooks to refresh cached content after edits.
That setup provided a browser-based editing workflow and a clear separation between content and code. It also meant maintaining database migrations, CMS configuration, storage integration, and the translation from editor content into the frontend.
For my own writing, I am comfortable working directly in Markdown. A separate editing application added more infrastructure than I needed for that workflow. The question became how much of it this particular site still needed.
Content alongside the site
Each article and case study now lives in a single MDX file. Frontmatter holds its title, description, and listing details; the body contains the writing. Content changes can be reviewed and versioned alongside the rest of the site.
Adding a page does not require updating a separate project array or content registry. The site discovers the files and uses their metadata for listings and previous/next navigation. Shared compilation steps generate heading anchors, the table of contents, and search and social metadata.
Most of the body is ordinary Markdown. When a case study needs a browser preview, diagram, or chart, MDX lets me place a shared component directly in the article. That keeps the writing straightforward without restricting every page to plain prose.
Performance by doing less at request time
The portfolio and article routes are pre-rendered during the production build. Reading a published article does not require a CMS or database lookup, and code highlighting happens during compilation rather than in the browser.
That moves content parsing and page rendering out of the reader’s request and into the build. The resulting pages can be served from a cache, with the article text already in the HTML. There is no browser-side content fetch needed before the writing can appear, and no syntax-highlighting library to download and run for code samples.
The previous CMS setup also cached content, so removing it does not automatically make every visit faster. The benefit is a simpler delivery path: published articles do not depend on CMS availability, database response times, or content-cache refreshes. Actual loading speed still depends on images, fonts, JavaScript, and hosting.
The site still uses Next.js, with client components for interactions, server-rendered listing routes, and a dynamic endpoint for generated social images. Individual articles and case studies get the benefits of pre-rendering while the application retains those dynamic features.
Reducing publishing infrastructure also leaves room for the details that make the site personal: expressive typography, a charcoal and lavender palette, an ASCII portrait on the homepage, and motion that respects reduced-motion preferences. Those choices belong to the interface; they do not need a CMS behind them.
The publishing trade-off
Content updates now go through the repository and a new build. I give up the CMS’s browser-based editing and draft publishing workflow in exchange for writing in the same environment where I maintain the site.
That is a useful fit for a personal portfolio with one author. A team with several editors, publishing permissions, or frequent updates independent of deployments would have different needs.
Existing article and project URLs remain in place, and the shared page layouts keep navigation and typography consistent. The change is in how content is authored and delivered, while the published work retains its place on the site.
Outcome
The current site has no CMS or content database dependency. Articles, case studies, and their images live with the application, and the build turns the local content into published pages.
The practical benefit is a smaller publishing setup to maintain, less work when serving an article, and a writing workflow that suits me. Content processing and code highlighting happen once per build, and published pages can be delivered without consulting a content backend. Publishing a piece of writing now starts with a Markdown file.