Most developer portfolios look the same. You know the template: hero section with a gradient, a "my work" grid, a tech stack icon row, a contact form. They're fine. They're also invisible. When a hundred people have the same template, the template stops communicating anything about the person behind it.
I rebuilt mine from scratch not because the old one was broken, but because it was saying the wrong things.
What the old template was communicating
The old site was a generic agency theme. It looked professional in a stock-photo way. Lots of gradients, some animated counters ("500+ projects delivered"), a testimonials carousel. The kind of site that exists to look like a tech company, not to demonstrate that you are one.
The problem isn't aesthetics — it's signal. When a potential client or employer visits your portfolio, they're trying to answer a specific question: is this person capable of building the thing I need? A template from ThemeForest answers that question poorly. It demonstrates that you can configure a theme. It doesn't demonstrate that you can architect a product.
There's a deeper issue too. Agency templates optimize for a particular audience: small business owners who want a local web shop. That's a real market, but it's not the only one. If you're also trying to attract product companies and engineering roles, the signal is confused. The site was doing too many things for too many audiences and not quite nailing any of them.
What I wanted to say instead
The new site has a clearer thesis: I'm a full-stack engineer who specializes in Next.js, React, and TypeScript. I work with startups and growing businesses. My work is production-quality — not just good-looking demos.
That thesis shaped every decision. The dark design system isn't a style choice — it's a signal that this is an engineering-first site. The command palette (⌘K) isn't a gimmick — it proves that I build the kinds of interactive details that differentiate good products from great ones. The AI chat bubble isn't marketing — it's a live demo of a skill.
The portfolio page isn't a grid of screenshots. Each project has a structured case study: the problem, the architecture, the tradeoffs I made, and what I'd do differently. That's the information an engineering manager actually wants.
The rebuild process
I structured the rebuild in phases so I wouldn't ship something half-finished. Phase 1 was the portfolio itself — the core content. Phase 2 was engineering hygiene: TypeScript strict mode, ESLint, Vitest tests, GitHub Actions CI, accessibility audit. Phase 3 was standout features: command palette, design system showcase page, Lighthouse performance badge, dark mode.
The sequence matters. Shipping the design system page before I had a lint pipeline or test suite would have been backwards. Engineering credibility comes from showing that the infrastructure is solid, not just that the features look impressive. Anyone can ship a cool UI. Fewer people ship a cool UI with 40 passing tests, a clean lint output, and a CI badge that stays green.
Phase 2 took longer than I expected — not because the individual pieces were hard, but because fixing the gap between "works on my machine" and "provably correct on every commit" requires confronting a lot of accumulated technical debt. There were apostrophes in JSX text nodes triggering ESLint. There were useEffect patterns that violated the rules of hooks. There was a @ts-ignore that needed to become @ts-expect-error (which then needed to be removed entirely when TypeScript shipped the types it was suppressing).
That kind of cleanup isn't glamorous. But it's also exactly what distinguishes production code from portfolio code, and the distinction matters.
The design system
The dark theme is built on CSS HSL custom properties with a Tailwind v4 @theme inline block. Every color in the site is a token:
@theme inline {
--color-background: hsl(var(--background));
--color-foreground: hsl(var(--foreground));
--color-primary: hsl(var(--primary));
/* ... */
}Dark mode is a single class swap — dark on the <html> element — with no JavaScript involved in the color calculation. The design system page at /design-system documents every token, every type size, every spacing value, and every component variant. It exists partly as documentation and partly as a proof point: if I can articulate the design system this clearly, I can build one for your product too.
What changed in practice
The most concrete outcome of the rebuild is that conversations are different. When I share the site now, the reaction is "this is impressive" rather than "nice site." That's a small difference in words but a meaningful difference in outcome. The old template created a pleasant impression. The new site creates a specific impression: this person builds production software.
The second outcome is personal. The rebuild forced me to think carefully about every decision: what is this page for, who is reading it, what do I want them to know afterward? That kind of intentional design thinking is exactly what I try to bring to client work. The portfolio is now a demonstration of the process, not just the result.
The stuff that's still missing
I'll be honest about the gaps. Performance in development is mediocre — 48 on Lighthouse when running locally, because development mode has no optimization. Production scores are substantially better but I haven't published them yet (the CI job that measures them runs against the live URL after deploy).
The blog is new. There's no newsletter. The case studies could be deeper. The portfolio has six projects and I'd like it to have twelve.
These are solvable problems and I'm working on them. The point isn't to wait until everything is perfect — it's to ship something that accurately represents where I am right now, with a foundation that makes the next version faster to build.