Most personal portfolio sites are static. They introduce the person, list a few projects, and link out to GitHub or LinkedIn.
That approach makes sense. A portfolio site should be simple, fast to navigate, and easy to maintain.
But while building my own site, I kept running into a different instinct: I did not want it to be just a set of pages. I wanted it to feel more like a product.
A lot of that came from the kind of work I have done professionally. Working on editorial tooling has made me think less about content as “just text on a page” and more about the workflows behind it. Who owns a document? How are revisions preserved? Where should the system enforce rules, rather than relying on the UI to behave correctly?
Those questions shaped this project from the beginning.
A portfolio site gets more interesting when content becomes a workflow
It is easy to think of a personal site as a finished artifact: a homepage, an about page, a projects section, maybe a blog.
But once I started thinking of publishing as an ongoing workflow rather than a one-time output, the project changed.
I wanted the site to do more than display information. I wanted it to support authoring, protected editing flows, and revision-aware content management. That shift made the project feel much closer to product engineering than to traditional portfolio-building.
The current shape of the platform
Today, the site is built with Next.js, React, TypeScript, Tailwind CSS, Clerk, Prisma, and PostgreSQL.
On the surface, it serves public-facing pages for my personal site. Underneath that, it also includes a private document workspace with markdown authoring, authenticated routes, protected API interactions, and document revision history.
The goal was not to add complexity for its own sake. It was to build a foundation that could support multiple content surfaces over time without feeling like separate systems stitched together. A personal site, a blog, and project writeups all become easier to reason about when they can grow from the same underlying content model.
What got more interesting than I expected
The most interesting part of this project has not been the visual layer. It has been the design decisions behind the workflow.
Once you move beyond static content, even a small project starts raising real engineering questions:
- How should revision history be modeled?
- What should be append-only?
- How should the system identify the latest version of a document while preserving full history?
- Where should ownership be enforced?
- How do you keep the UI simple when the workflow underneath is not?
Those are the kinds of questions I enjoy most, because they sit at the boundary between product design and engineering design.
A user should not need to think about any of this. They should just feel that the system is reliable, predictable, and easy to use. But creating that experience usually means making deliberate choices below the surface.
Why revision history mattered
I wanted the platform to treat content as something that evolves, not something that simply gets overwritten. That led me toward a revision-based model, which ended up shaping more of the system than I expected.
Building small, but not casually
One thing I wanted to avoid was letting the project become a typical side-project codebase where everything lives in one place because “it’s just personal.”
Instead, I tried to keep the project small while still respecting boundaries.
The monorepo separates app runtime concerns from database concerns. The web app handles the user-facing experience, routes, and API handlers. The database package owns schema and persistence-related concerns. Shared types are used where they clarify contracts rather than blur them.
That does not make the project enterprise-scale. It just makes it easier to evolve without paying unnecessary complexity costs later.
Closing thought
This started as a personal site, but it quickly became more interesting once I stopped thinking of it as a collection of pages and started thinking of it as a content system.
That has been the most rewarding part of the project so far: building something small enough to experiment with, but real enough to force better decisions.