Why I over-engineered my portfolio — and why I'd do it again

I spent way too long talking about building my portfolio. Reading about Next.js, bookmarking design inspiration, planning the perfect stack. At some point I just got tired of it and decided to ship something real.

That decision changed how I think about side projects entirely.

The stack: deliberate choices, not hype

Next.js App Router was the obvious choice — popular, well-documented, and I wanted to finally work with the Server/Client Components split in a real project rather than just read about it. SEO metadata, JsonLd, proper page structure. Not because a portfolio needs enterprise-grade SEO, but because I wanted to know how it actually works under pressure.

GSAP for animations was a conscious rebellion. Everyone uses Framer Motion. It's great, it's easy, and because of that — every portfolio looks the same. GSAP has a steeper learning curve but gives you precise control. I wanted the animations to feel like a decision, not a default.

TypeScript everywhere. Even in static data like jobData.ts. Overkill? Maybe. But muscle memory matters — I write TypeScript the same way whether it's a toy project or a distributed system with 30 engineers.

What went wrong

• The SEO title was double-templating for weeks before I caught it.
  "Experience | Front-End Architect & Tech Lead | Code Nomad" — one extra template wrapper in createMetadata. A tiny bug, slightly embarrassing to notice after deployment.

• The blog launched with a few placeholder posts while I was testing the publishing pipeline and metadata setup.

• Some of those experimental tags — including "misie" and "lubisie" — briefly made their way into Google's index before I cleaned them up.

Turns out search engines move faster than your refactoring cycle.

What I'd do differently

Plan first, build second. Right now my workflow is:

1. Sit down
2. Think of something to fix
3. Fix it

It works, but it's reactive. For a commercial project with a team that's a recipe for technical debt. I know this — and I still do it on my own portfolio, because sometimes the point is just to move.

What I learned as a Tech Lead

The difference between over-engineering your own project and a client's project is accountability.

On my portfolio I can refactor the SEO setup at 11pm because I feel like it. On a project with 30 engineers, that same impulse needs a ticket, a discussion, and a migration plan.

Building this taught me to separate those two modes deliberately:

• Exploration
• Delivery

Both are valid. Knowing which one you're in is the skill.

The real lesson

Someone asked me recently if their portfolio needs to be perfect before they publish it.

It doesn't have to be perfect. It has to be authentic — because behind all of it, there's a human.

Ship it. Fix it live. Write about what you learned.