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

---

title: 'Dlaczego przesadziłem z architekturą portfolio — i dlaczego zrobiłbym to znowu' excerpt: 'Za długo tylko mówiłem o budowaniu portfolio. W końcu miałem tego dość i postanowiłem wypuścić coś prawdziwego.' featuredImage: '/images/featured/portfolio-post.webp' date: '2026-02-26' publishDate: '2026-02-26T10:00:00Z' readTime: 4 tags: ['nextjs', 'react', 'typescript', 'gsap', 'portfolio']

Za długo tylko mówiłem o budowaniu portfolio. Czytałem o Next.js, zapisywałem inspiracje projektowe, planowałem idealny stack. W pewnym momencie po prostu miałem tego dość i postanowiłem wypuścić coś prawdziwego.

Ta decyzja całkowicie zmieniła moje podejście do projektów pobocznych.

Stack: świadome wybory, nie hype

Next.js App Router był oczywistym wyborem — popularny, dobrze opisany i w końcu chciałem popracować z podziałem na Server Components i Client Components w prawdziwym projekcie, a nie tylko o nim czytać.

SEO metadata, JsonLd, poprawna struktura stron. Nie dlatego, że portfolio potrzebuje SEO na poziomie enterprise. Raczej dlatego, że chciałem sprawdzić, jak to działa w praktyce, kiedy faktycznie trzeba coś dowieźć.

GSAP do animacji był świadomym buntem. Wszyscy używają Framer Motion. Jest świetny, prosty i właśnie dlatego wiele portfolio zaczyna wyglądać podobnie.

GSAP ma wyższy próg wejścia, ale daje dużo większą kontrolę. Chciałem, żeby animacje wyglądały jak decyzja, a nie jak domyślny wybór.

TypeScript wszędzie. Nawet w statycznych danych typu jobData.ts.

Przesada? Może.

Ale pamięć mięśniowa ma znaczenie. Piszę TypeScript tak samo, niezależnie od tego, czy robię mały projekt dla siebie, czy system rozwijany przez 30 inżynierów.

Co poszło nie tak

• SEO title przez kilka tygodni miał podwójny template, zanim to zauważyłem. "Experience | Front-End Architect & Tech Lead | Code Nomad" — jeden dodatkowy wrapper w createMetadata. Mały błąd, trochę wstydliwy do zauważenia dopiero po deployu.

• Blog wystartował z kilkoma placeholderowymi wpisami, kiedy testowałem pipeline publikacji i konfigurację metadanych.

• Część eksperymentalnych tagów — w tym "misie" i "lubisie" — zdążyła na chwilę trafić do indeksu Google, zanim je posprzątałem.

Okazało się, że wyszukiwarki działają szybciej niż mój cykl refaktoryzacji.

Co zrobiłbym inaczej

Najpierw plan, potem budowanie.

Mój obecny workflow wygląda mniej więcej tak:

1. Siadam
2. Wymyślam coś do poprawienia
3. Poprawiam

To działa, ale jest reaktywne. W komercyjnym projekcie, z zespołem, to prosta droga do długu technicznego.

Wiem o tym — i nadal robię tak przy własnym portfolio, bo czasami chodzi po prostu o to, żeby ruszyć z miejsca.

Czego nauczyłem się jako Tech Lead

Różnica między over-engineeringiem własnego projektu a over-engineeringiem projektu klienta to odpowiedzialność.

W swoim portfolio mogę o 23:00 przepisać setup SEO, bo akurat mam na to ochotę.

W projekcie, nad którym pracuje 30 inżynierów, ten sam impuls potrzebuje taska, rozmowy i planu migracji.

Budowanie tego portfolio nauczyło mnie świadomie rozdzielać dwa tryby pracy:

• eksplorację
• dowożenie

Oba są potrzebne.

Umiejętność polega na tym, żeby wiedzieć, w którym trybie jesteś.

Prawdziwa lekcja

Ktoś ostatnio zapytał mnie, czy portfolio musi być perfekcyjne, zanim je opublikuje.

Nie musi być perfekcyjne. Musi być autentyczne — bo za tym wszystkim stoi człowiek.

Wypuść to. Poprawiaj na żywo. Napisz, czego się nauczyłeś.