Przemysław Zalewski

Next.js, z Vercelem i bez

Programista Next.js, który powie Ci też, kiedy Next.js jest problemem

App Router, Server Components, streaming, reguły cache, których nikt nie pamięta. Wdrażam Next.js, gdy na to zasługuje, i ratuję aplikacje tam, gdzie nie zasłużył. Niżej pokaz, który mierzy różnicę między kaskadą żądań a jedną strumieniowaną odpowiedzią.

Dostępny od listopada 2026 · Wrocław, zdalnie

Przemysław Zalewski
  • „someone you can always count on”publiczna rekomendacja na LinkedInie
  • „a true bias for action”CTO klienta, na LinkedInie
  • 15+ latwydawania oprogramowania
  • Bezpłatna rozmowa, bez prezentacji30 minut, potem decydujesz
9lat TypeScriptu, Reacta i Node.js
2017React na produkcji od
~30%zmergowanych PR w 2026 otworzył agent AI, ~85% z nich przejrzałem
15+lat wydawania oprogramowania

Dlaczego ja

Ratunek, z liczbami

Sto żądań przy pierwszym wejściu, force-dynamic wszędzie, regresja przy każdym podbiciu wersji. Najpierw mierzę, potem naprawiam trzy rzeczy, które mają znaczenie, potem oddaję checklistę na resztę.

Streaming zrobiony dobrze

Jedna odpowiedź HTML, sloty wypełniane poza kolejnością w miarę wyników, bez hydratacji, gdy jej nie trzeba. Zbudowałem to dla wyniku agentów bez frameworka klienckiego. Next.js też tak umie, jeśli nikt nie walczy z domyślnymi ustawieniami.

Poza Vercelem

Next.js na własnym serwerze Node.js albo w Dockerze, albo część statyczna na Cloudflare. Uczciwa odpowiedź czasem brzmi „zostańcie i idźcie all-in w Vercela”. Powiem, która to.

Podatności tego samego dnia

Gdy spadł React2Shell, załatałem nasz produkt w dniu publikacji ostrzeżenia i przeszukałem kod pod tę samą klasę błędu. Aplikacje Next.js dostają to samo.

Dowody

Praca, którą mogę pokazać

Problem, co zrobiłem, efekt. Nazwy klientów tylko tam, gdzie wolno mi ich użyć.

Strumieniowanie wyniku agenta w jednym żądaniu HTML, bez frameworka po stronie klienta

Problem
Wynik agenta przychodzi poza kolejnością i trwa. Strona, która czeka na wszystko, wygląda na zepsutą.
Co zrobiłem
Jedna odpowiedź HTML strumieniowana z serwera, sloty wypełniane poza kolejnością w miarę wyników, bez hydratacji, bez frameworka klienckiego.
Efekt
Pierwsze malowanie w milisekundach, reszta dopływa na żywo. Ten sam pomysł napędza pokaz strumienia na stronie Next.js.

strumieniowany HTML bez hydratacji

Zobacz też: JavaScript

Centrum pomocy przeniesione z WordPressa do repo jako docs-as-code

Problem
Nieutrzymywany help na WordPressie: czerwony w audytach, bez sitemapy, wygasające certyfikaty, pluginy, których nikt nie rozumiał.
Co zrobiłem
Markdown w repo, wersjonowany z produktem, wszystkie języki generowane automatycznie, linkowanie wewnętrzne, 301 dla każdego starego adresu, help dopisany do Definition of Done.
Efekt
Jedna maszyna mniej do zepsucia na urlopie, dokumentacja zgodna z produktem, lepsze SEO i GEO, kontekst, który czytają agenci.

docs-as-code 301s i18n

Zobacz też: Cloudflare · Utrzymanie i CI/CD

Reakcja tego samego dnia na React2Shell i inne podatności

Problem
Krytyczne podatności w Reakcie, Node.js, WordPressie i OpenSSH spadają bez ostrzeżenia, a skanery z PoC przychodzą kilka dni później.
Co zrobiłem
Stały wzorzec: oficjalne źródło, łatka tego samego dnia, mitygacja w WAF, przeszukanie własnego kodu regexpem pod tę samą klasę podatności, flagi hardeningu Node.js, lektura dla zespołu.
Efekt
React2Shell załatany w dniu publikacji ostrzeżenia, na kilka dni przed uruchomieniem publicznych skanerów.

łatka tego samego dnia WAF przegląd kodu

Zobacz też: TypeScript i Node.js · Utrzymanie i CI/CD

Jedna noga w drzwiach

Nie czas na projekt? Zacznij mniejszym krokiem.

Dwa sposoby, żeby zobaczyć, jak pracuję, zanim zamówisz sprint. Stały zakres, liczba na piśmie po krótkiej rozmowie.

Audyt kodu Next.js, tydzień

Czytam repo, CI, testy, bezpieczeństwo i miejsca, których zespół unika. Dostajesz pisemny raport z ustaleniami według ryzyka, plan z kamieniami milowymi i decyzję go/no-go, którą da się obronić. Robiłem taki audyt dla dużego software house’u, zanim jego klienci zobaczyli kod.

Code review jednego pull requesta albo modułu

Przyślij diff, który Cię martwi. W kilka dni dostajesz komentarze do linii, trzy rzeczy, które zmieniłbym najpierw, i werdykt: zmergowałbym czy nie.

Zapytaj o audyt Najpierw bezpłatna rozmowa 30 min. Jeśli audyt to złe narzędzie, powiem to na rozmowie.

Pokaz na żywo

Kaskada kontra strumień

Po lewej: dwanaście żądań po kolei, kształt strony, która pobiera dane w każdym komponencie. W środku: te same dwanaście równolegle. Po prawej: jedna strumieniowana odpowiedź HTML z Workera, pięć slotów przychodzi poza kolejnością. Oś czasu pokazuje czas do pierwszego bajtu, każdy kawałek i sumę.

Ładuję pokaz…

Potem odpowiedz na pięć pytań pod osią czasu. To te, które zadaję na rozmowie ratunkowej.

Jak to działa

Trzy kroki od tej strony do działającego projektu.

  1. 1

    Rozmowa 30 minut

    Opisujesz produkt i problem. Ja zadaję pytania, które zadałbym pierwszego dnia. Jeśli nie jestem właściwą osobą, mówię to i wskazuję kogoś, kto jest.

  2. 2

    Zakres na piśmie

    Potem krótki plan na piśmie: co budujemy najpierw, co mierzymy, jak pracujemy i ile to kosztuje. Bez prezentacji.

  3. 3

    Coś do dotknięcia w pierwszym tygodniu

    Pierwszy wycinek wychodzi w pierwszym tygodniu: wdrożony, zmierzony, do przejrzenia. Dalej tempo wyznaczają liczby.

Dopasowanie

Czy to pasuje?

Dobre dopasowanie, gdy

  • Potrzebujesz seniora, który bierze odpowiedzialność za dowiezienie, nie pary rąk
  • Produkt ma wyjść i być mierzony, z product managerem albo bez
  • Współpraca solo albo zespół do czterech osób
  • TypeScript, React, Node.js, Cloudflare, Postgres, PostHog

Raczej nie, gdy

  • Program, który potrzebuje dziesięcioosobowego zespołu dostawcy
  • Stack zbudowany wokół Javy, Pythona albo chmury, której nie sprzedaję
  • Body leasing na godziny bez wpływu na sposób pracy
  • Start przed listopadem 2026

Styl pracy

Jak pracuję

Review jako rzemiosło

Setki przejrzanych pull requestów. Patrzę na produkt i jego powody. Kod jest drugi.

Zero bug policy

Błąd jest naprawiony albo świadomie zamknięty, nigdy odłożony. Alerty i śledzenie błędów w każdym projekcie, więc o problemach dowiaduję się przed klientem.

Mierzone, nie zakładane

PostHog w każdym projekcie od pierwszego dnia. Plan zdarzeń per funkcja i dashboardy, które zarząd naprawdę czyta.

FAQ

Pytania, które padają przed umówieniem rozmowy

Czy powinniśmy zrezygnować z Next.js?
Czasem. Jeśli produkt to strona z treścią, raczej nie. Jeśli to długowieczna aplikacja ze stabilnym API, wdrażana poza Vercelem, framework może kosztować więcej, niż daje. Robię krótki audyt i daję odpowiedź z liczbami, włącznie z „zostańcie”. Jeśli odpowiedź brzmi „czysty React”, ta praca jest na stronie o Reakcie.
Co psuje się w App Routerze?
Fetch w każdym komponencie bez planu cache, server actions używane jako API, wszystko dynamiczne, bo jedna rzecz była, i aktualizacje zmieniające semantykę cache pod nogami. Wszystko do naprawy, wszystko mierzalne.
Wdrożysz Next.js poza Vercelem?
Tak: serwer Node.js, Docker na VPS-ie albo eksport statyczny z dynamicznymi kawałkami na Cloudflare Workers. Powiem, które funkcje tracicie i czy ich używaliście.
Jak wygląda ratowanie aplikacji?
Tydzień pierwszy: pomiar, czytanie, spisanie wniosków. Tygodnie od drugiego do czwartego: trzy poprawki o największym efekcie, każda za testem. Potem checklista, którą zespół przejdzie beze mnie. To sprintowy szczebel drabinki ofert.
Budujesz też nowe aplikacje w Next.js?
Tak, gdy pasuje: strony z dużą ilością treści, marketing plus aplikacja w jednym repo, zespoły, które już go znają. Z planem cache spisanym pierwszego dnia.
Od kiedy możesz zacząć?
Od listopada 2026. Umów rozmowę, zaczniemy od tygodnia pomiarów.
Przemysław Zalewski

Sprawdźmy to w 30 minut

Bezpłatna rozmowa 30 minut. Ty przynosisz problem, ja pytania. Bez cen na tej stronie, bo najpierw zakres.

Jeśli nie jestem właściwą osobą, powiem to na rozmowie i wskażę kogoś lepszego.

Po umówieniu: zaproszenie do kalendarza, potem rozmowa. Nic więcej do wypełniania.

Dostępny od listopada 2026 · B2B albo etat · Wrocław, zdalnie