Building my portfolio in public
Every developer reaches a point where they ask: do I actually need a portfolio? I asked myself that question for about six months before I finally sat down and built this one. The answer I landed on wasn't just "yes" — it was "yes, and make it weird."
Why build it at all?
There's a version of a portfolio that's basically a prettier resume. Name, skills, two GitHub links, contact form. Done. I've seen hundreds of them, and I genuinely can't remember any of them after closing the tab.
I didn't want to build that. I wanted something that felt like me — a place that, if someone spent 10 minutes on it, they'd walk away knowing what I care about, what I'm building, what I'm reading, and what I'm watching. Not just what technologies I know.
That's the idea behind putting my entire life on the internet. Not in a social media way — more in a "this is a living document of who I am right now" way.
The stack decisions
I chose Next.js 14 App Router because I wanted server components, file-based routing, and the ability to render MDX content. TypeScript was non-negotiable — more on that in another post. Tailwind CSS for styling because I'd rather think in utility classes than maintain a stylesheet that grows out of control after week three.
The font choices were deliberate too. Playfair Display for display headings gives it a slightly editorial feel. Inter for body text because it's one of the most readable sans-serifs at small sizes. JetBrains Mono for labels and meta — it's designed for code, and it looks sharp when used for small caps tracking.
The best developer portfolio is the one that makes someone want to have a conversation with you — not just add you to a shortlist.
Building in public, actually
"Building in public" gets thrown around a lot. It usually means tweeting progress screenshots. For me it means something more literal: the source of this site is readable, the books I've read are listed, the movies I've watched are listed, the projects I'm working on are listed with their actual status.
I find it keeps me honest. If I say I'm "ongoing" on something, it's visible. If I've been "next up" on a book for six months, I know. It creates a kind of accountability that a private notes app never does.
What I'd do differently
The one thing I underestimated was the content. The code took maybe three weeks of evenings. Writing the actual words — the project descriptions, the book notes, the blog posts — that's ongoing. Code is the easy part.
If you're building your own, start with the content. Figure out what you actually want to say about yourself, then build the container for it.
Final thoughts
This site is never finished. That's kind of the point. I'll add things as I build them, read them, watch them, and think them. If you're reading this, you're seeing a version of it — not the version.
If you want to build something similar, the stack is open and the design patterns are pretty standard. The part that's not standard is what you choose to put in it. That's the whole game.