To nie była zmiana „bo coś nowego”
Ta decyzja nie zaczęła się od technologii.
Zaczęła się od frustracji.
Moje portfolio działało. Było szybkie, proste, postawione na znanym stacku.
Problem w tym, że nic z niego nie wynikało.
Było stroną-wizytówką.
Nie było narzędziem.
A ja potrzebowałem miejsca, które pozwala regularnie publikować, sensownie ogarniać SEO i realnie budować markę osobistą — a nie tylko „być w internecie”.
Punkt wyjścia był pragmatyczny
Startowałem z Reactem (CRA) i Firebase.
Na początku to miało sens: szybkie wdrożenie, minimum konfiguracji, niskie koszty poznawcze.
Ale gdy pomyślałem o blogu — a nie pojedynczym wpisie — zaczęły wychodzić pęknięcia:
- SEO było raczej „jakoś jest”, a nie „mamy nad tym kontrolę”
- brakowało sensownego panelu do publikacji
- każdy wpis oznaczał grzebanie w kodzie
- całość słabo skalowała się jako system do tworzenia treści
I wtedy pojawiło się właściwe pytanie:
Czy chcę dalej utrzymywać prostą stronę,
czy zbudować system, który pracuje na mnie w długim terminie?
Rozważałem trzy drogi — żadna nie była idealna
Pierwsza opcja była najłatwiejsza: zostać przy tym, co jest.
Najmniej zmian, najszybszy start.
Ale też najsłabsze fundamenty pod blog i SEO.
Druga skrajność to pełne Django z własnym CMS-em.
Technicznie — marzenie.
Kontrola, workflow, rozbudowany backend.
Tylko że koszt był realny: czas, złożoność, infrastruktura.
A ja nie budowałem redakcji z zespołem, tylko blog jednego programisty.
Trzecia opcja była kompromisem: Next.js + headless CMS.
I dopiero tutaj coś zaczęło się składać.
Dlaczego padło na Next.js + Sanity
To nie był wybór „bo modne”.
To był wybór najbardziej pragmatyczny.
Chciałem:
- publikować szybko,
- mieć kontrolę nad SEO per wpis,
- nie budować CMS-a od zera,
- oddzielić treść od frontendowej logiki,
- zachować dobrą wydajność.
Ten stack pozwalał to wszystko osiągnąć bez przepalania miesięcy pracy i bez komplikowania życia bardziej, niż to konieczne.
Nie idealnie.
Ale wystarczająco dobrze — i rozsądnie.
Co faktycznie wdrożyłem
Migracja nie polegała tylko na „przepisaniu frontu”.
To był świadomy projekt:
- wielojęzyczny routing,
- pełne metadata per strona i per wpis,
- canonicale, Open Graph, JSON-LD,
- dynamiczne sitemap i robots,
- spójny model treści w CMS-ie,
- jasny podział: frontend robi frontend, CMS trzyma content.
Efekt?
Pisanie przestało być operacją techniczną.
Co zyskałem — i czego to mnie kosztowało
Największa zmiana jest banalna, ale kluczowa:
publikowanie przestało boleć.
SEO wreszcie jest świadomą decyzją, a nie afterthoughtem.
Struktura sprzyja regularnemu pisaniu.
Całość ma sens jako długoterminowy system.
Cena?
Większa złożoność niż statyczna strona.
Migracja, która wymagała dopieszczenia detali.
Konieczność pilnowania spójności treści.
Ale to jest koszt, który świadomie akceptuję.
Czy dziś wybrałbym coś innego?
Tak.
Gdybym budował produkt z ciężką logiką domenową, rozbudowanymi workflow i zespołem redakcyjnym — Django wygrałoby bez dyskusji.
Ale przy celu:
SEO-ready blog + regularne publikowanie + budowanie marki osobistej
ten wybór okazał się po prostu trafny.
Podsumowanie
To nie była decyzja technologiczna.
To była decyzja o tym, jakim narzędziem ma być moja strona.
Nie ładnym portfolio.
Nie kolejnym side-projektem.
Tylko systemem, który pozwala myśleć długoterminowo i konsekwentnie robić swoje.