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ę.
Next.js, z Vercelem i bez
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

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ę.
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.
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.
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
Problem, co zrobiłem, efekt. Nazwy klientów tylko tam, gdzie wolno mi ich użyć.
Zobacz też: JavaScript
Zobacz też: Cloudflare · Utrzymanie i CI/CD
Zobacz też: TypeScript i Node.js · Utrzymanie i CI/CD
Jedna noga w drzwiach
Dwa sposoby, żeby zobaczyć, jak pracuję, zanim zamówisz sprint. Stały zakres, liczba na piśmie po krótkiej rozmowie.
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.
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.
Pokaz na żywo
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
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.
Potem krótki plan na piśmie: co budujemy najpierw, co mierzymy, jak pracujemy i ile to kosztuje. Bez prezentacji.
Pierwszy wycinek wychodzi w pierwszym tygodniu: wdrożony, zmierzony, do przejrzenia. Dalej tempo wyznaczają liczby.
Dopasowanie
Styl pracy
Setki przejrzanych pull requestów. Patrzę na produkt i jego powody. Kod jest drugi.
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.
PostHog w każdym projekcie od pierwszego dnia. Plan zdarzeń per funkcja i dashboardy, które zarząd naprawdę czyta.
FAQ

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