Disecting my portfolio

I spent five years building my personal site. When I say five years, I do not mean five years of nonstop coding. I mean five years of starting, stopping, rewriting, deleting, and rebuilding. Some months I shipped features every week. Some months I opened the repo, stared at it, and closed it.

It took me that long because this project was never just a portfolio. It was a mirror. Every design decision felt personal, every technical choice felt permanent, and every unfinished page felt like public evidence that I was not "ready" yet.

At some point I realized the real blocker was not technology. It was perfectionism dressed up as engineering standards.

Once that clicked, progress became simpler: build in public, keep the stack boring, and optimize for consistency over intensity.

What I learned (the hard way)

1. Protect your energy first

   There was a period where I kept pushing late-night sessions, thinking discipline alone would finish the site. Instead, quality dropped, decisions got worse, and I started rewriting things I had already solved.

   Burnout does not always look dramatic. Sometimes it looks like small, endless refactors that do not move the product forward.

2. Ship before you feel ready

   I used to wait for "one more polish pass" before sharing anything. That delay cost me months.

   The first time I shared a rough version, feedback immediately exposed what mattered and what did not. Readers did not care about my perfect spacing system. They cared about clarity, speed, and whether the writing felt human.

3. Design quality comes from iteration, not imagination

   My biggest design improvements did not happen in Figma. They happened after shipping real pages and seeing where users slowed down, skipped, or bounced.

   Good taste is useful, but production feedback is better.

4. Use tools that reduce cognitive load

   I like new tech as much as anyone, but shiny tools can become a full-time side quest. For a personal site, reliability is underrated.

   Every tool in this stack had one job: help me publish faster with less maintenance.

5. Treat each version as a milestone, not a mistake

   I used to cringe at old versions. Now I see them as snapshots of skill growth.

   V1 taught me momentum. V2 taught me structure. V3 taught me restraint. Each rewrite paid for the next one.

How I built this site (engineering overview)

I built everything in a monorepo using Turborepo and pnpm. That gave me a clean way to separate the app, UI primitives, and content logic while still sharing types and tooling.

The web app itself is Next.js + TypeScript.

I wanted server rendering, solid routing, and predictable DX without fighting the framework. TypeScript helped keep content models and UI contracts explicit, which matters a lot once the site grows beyond a few static pages.

For styling, I used Tailwind CSS with shadcn/ui.

Tailwind gave me speed and consistency. shadcn gave me composable components I could adapt to my own visual language instead of forcing a pre-baked theme. The goal was not to look "different" for the sake of it, but to create a system where adding a new section does not require a new design language every time.

For content, I write in MDX and validate/shape it with content-collections.

That decision was huge. It means content is not just text files; it is typed data. Frontmatter gets validated, references stay consistent, and new posts slot into the site without custom parsing hacks.

Design starts in Figma, but never ends there.

I prototype quickly, move into code early, then refine based on real reading flow. A section that looks great in a static mock can feel heavy in a live page. Real content is the truth test.

Why this version finally worked

I stopped trying to build a "final" portfolio and started building a living system.

Now the workflow is simple:

1. Write or refine content in MDX.
2. Reuse existing UI blocks whenever possible.
3. Ship small changes frequently.
4. Improve based on usage and feedback.

No hero rewrites. No dramatic framework migrations. Just steady, compounding improvements.

If you are building your own site, this is my honest advice: pick a stack you can maintain when life gets busy, publish before your inner critic is satisfied, and let iteration do the heavy lifting.