Engineering blog
I Built My Portfolio the Same Way I Build Products
Shipping a personal site without product thinking is like launching a SaaS without user research. Here's what changed when I stopped treating mine like a resume.
I Built My Portfolio the Same Way I Build Products
The first version of this site was an HTML file with my name on it. Honestly it looked fine. Clean, dark mode, some links. But every time I sent it to someone and waited for a response, I knew the problem wasn't the design — it was that nothing on the page showed *how I work*. It just told people what I claimed to know.
That bothered me for a while. Then I read an internal doc at a company I was contracting for, where their recruiting team said something that stuck with me: *"We hire the portfolio, not the resume."*
The shift: treating it like a real product
When I started this version, I made one rule for myself: every decision I'd normally make for a client product, I had to make here too.
That meant:
- A real content strategy — not just listing tech stacks, but explaining what I actually built and why it mattered
- Routing and information architecture — three-click rule to anything important
- Performance discipline —
next buildoutput showing no large JS bundles - A deployment pipeline — Vercel with branch previews, not "just drag and drop"
- Real writing — the blog has to prove I can explain things, not just build them
The difference between a templated portfolio and a product-minded one shows up in small things. Variable naming. Component structure. Whether the 404 page exists. Whether the ESLint config is real or ignored.
What surprised me along the way
I underestimated how long the projects section would take. Describing a project is harder than building it — you have to decide what to highlight, what to leave out, and what the reader actually cares about. A recruiter doesn't care that I used Prisma. They care that I built an auth system that handles 3000+ users without session leaks.
The sandbox demos were the part I'm most proud of. Instead of screenshots, each project has a working interactive demo that runs the actual compiled frontend in a sandboxed iframe. Visitors see the real UI, not a mockup.
The engineering signal
If you're reading this and building your own portfolio: the technical choices matter less than the consistency of thought behind them. Pick a stack, understand it deeply, and let that show in how the site is structured.
Good signal comes from naming, structure, documentation, and the absence of messy shortcuts. A hiring engineer reviewing the repository should feel like they're reading production code — because that's exactly what this is.