Ile naprawdę kosztuje przerobienie strony po freelancerze

Decyzja o tym, czy stronę naprawiać, czy pisać od nowa, sprowadza się do trzech rzeczy: stanu kodu, wieku frameworka i tego, jak zaprojektowana jest baza danych. Jeśli kod ma TypeScript, aktualną wersję frameworka i sensowną bazę, naprawa jest tańsza i szybsza. Jeśli wszystko trzeba zaczynać od początku, lepiej zaplanować to porządnie, w kawałkach krótszych niż trzy miesiące, najlepiej z wykorzystaniem wzorca Strangler Pattern.

Reszta tego tekstu opisuje to, co widzimy w kodzie najczęściej, jakie problemy są wciąż aktualne w 2026 roku, jak wygląda framework decyzyjny oraz dwa konkretne przykłady z naszego portfolio.

Co kilka tygodni rozmawiamy z kimś, kto w przeszłości zlecił stronę freelancerowi. Czasem była to oferta z ogłoszenia, czasem polecenie, czasem znajomy informatyk po godzinach. W większości przypadków przed kontaktem z nami minęło już kilka albo kilkanaście miesięcy i klient widzi, że coś jest nie tak: Google nie indeksuje stron, ładowanie idzie sześć sekund, formularz kontaktowy nie wysyła maili, a osoba, która stronę napisała, przestała odbierać wiadomości.

Ten tekst to próba zebrania w jedno miejsce wszystkiego, co wynosimy z takich rozmów oraz z migracji, które do tej pory zrobiliśmy. Patrzymy na to bardziej jak na raport z obserwacji rynku niż na argumentację sprzedażową. Chodzi o to, żeby ktoś, kto siedzi w identycznej sytuacji, mógł szybko ocenić, gdzie jest, i podjąć rozsądną decyzję, zanim wyda dwa razy więcej, niż musi.

Dwa konkretne przykłady, na których będziemy się tu opierać, znajdują się dalej: Fundacja Instytut Profilaktyki Zakażeń (która prowadzi przychodnię Centrum Medycyny Zapobiegawczej i Rehabilitacji) oraz Fundacja Znajdki ze schronisk dla zwierząt. Obie weszły do nas w klasycznej sytuacji "porzuconego projektu" i obie pokazują, czego ten typ migracji wymaga w praktyce.

Lista nie jest kompletna i każda historia ma własne niuanse. Mimo to, kiedy klient przychodzi z prośbą o ocenę strony po freelancerze, zwykle przynajmniej trzy z poniższych punktów występują razem.

WordPress w 2010 roku był rewolucją: każdy mógł postawić stronę w weekend, bez programisty. Ta sama zaleta dwadzieścia lat później bywa wadą.

Powód jest prosty. Dziś nie WordPress jest najszybszą drogą do gotowej strony. Asystent AI w Cursorze albo Claude Code potrafi w ciągu kilku godzin postawić aplikację Next.js z TypeScriptem, autoryzacją, formularzem kontaktowym, ciemnym motywem, podstawową dostępnością i deploymentem na własny serwer. To, co WordPressowi i jego dziesięciu wtyczkom zajmowało dwa tygodnie, dziś jest jednym dniem pracy z czystym kodem, który da się czytać i utrzymywać.

Druga sprawa to ociężałość. Klasyczna instalacja WordPressa, której się przez kilka lat nie patrzyło na ręce, zwykle wygląda tak: trzydzieści wtyczek (sześć od SEO, trzy od cache, dwie od formularzy, każda chce być najważniejsza), motyw z marketu, builder w stylu Elementora, wszystko ładuje się w jednej fali, każde żądanie idzie do PHP i bazy danych, pamięć podręczna nie działa po drugim zalogowaniu administratora. PageSpeed na mobile pokazuje czterdzieści, LCP siedem sekund, Core Web Vitals niezdane.

Trzecia rzecz, coraz ważniejsza w 2026 roku: WordPress nie współgra dobrze z nowoczesnymi narzędziami AI. Nie chodzi o to, że nie ma wtyczek do ChataGPT, bo są ich dziesiątki. Chodzi o to, że jego architektura, monolityczna i oparta o PHP, nie umie wystawić się na zewnątrz w sposób, jakim oczekują dzisiejsi agenci AI, edge functions i typowanie po stronie API. Crawlery typu GPTBot, ClaudeBot czy Perplexity na ciężkim WordPressie z JavaScriptem we wtyczkach widzą fragment treści albo nic.

WordPress nadal działa i nadal bywa dobrym wyborem. Dla bloga z dwoma wpisami miesięcznie albo prostej strony statutowej jest w porządku. Problem zaczyna się tam, gdzie wchodzi skala, dynamika, integracje albo widoczność oparta o AI. Wtedy każda kolejna wtyczka jest długiem technicznym, który ktoś kiedyś zapłaci.

Nowy problem 2026 roku. Wykonawca wkleja kod sugerowany przez asystenta AI i nie sprawdza, co dokładnie robi. Rezultat jest charakterystyczny: trzy biblioteki realizujące to samo, niespójne nazewnictwo, fragmenty kodu z zupełnie innego stacku, komentarze "TODO: dokończyć". Strona działa, dopóki nikt nie próbuje jej zmienić. Kiedy klient prosi o drobną korektę, okazuje się, że zmiana w jednym miejscu psuje trzy inne.

W 2026 cztery na pięć projektów frontendowych ma TypeScript. Brak typów to czerwona flaga widoczna z daleka. Bez typowania każda zmiana jest loterią: zmieniasz nazwę pola w API, a trzy miejsca w aplikacji się psują, bo nikt nie wiedział, że tych miejsc używają. TypeScript w połowie też bywa problemem, bo wystarczy jedno wymijające "any" we właściwym miejscu i cała sieć typów się rozsypuje.

Logowanie napisane bez gotowego, sprawdzonego rozwiązania (Supabase Auth, Auth.js, Clerk). Brak ograniczenia liczby żądań na endpointach logowania, hasła w bazie zapisywane bez aktualnego algorytmu haszowania, odzyskiwanie hasła przez wysłanie nowego maila bez tokenów z czasem ważności. Kategoria błędów, która kończy się incydentem RODO, jeśli ktoś z zewnątrz spojrzy na to z uwagą.

Brak narzędzi do migracji schematu. Zmiany robione ręcznie w phpMyAdminie czy bezpośrednio w psql na serwerze produkcyjnym. Środowiska deweloperskie i produkcyjne są w różnych stanach. Każda nowa funkcjonalność wymaga manualnej synchronizacji i co kilka deployów coś się rozjeżdża.

W każdej z tych historii pojawia się również jeden lub kilka z poniższych: sekrety w repozytorium git (klucze API, hasła SMTP w tekście jawnym), brak monitoringu (błąd na produkcji wykrywany telefonem od klienta), brak dostępności (formularze bez etykiet, kontrast poniżej WCAG AA), niezabezpieczone API (endpointy bez autoryzacji, brak rate limitingu), polityka prywatności skopiowana z innej strony bez sprawdzenia, czy odpowiada faktycznym praktykom.

To najtrudniejsza decyzja w całym procesie. Zanim podejmiesz ją intuicyjnie, warto znać argumenty obu stron.

Klasyczny argument przeciwko przepisywaniu od zera pochodzi od Joela Spolsky'ego, współtwórcy Stack Overflow. W 2000 roku napisał, że Netscape, decydując się na przepisanie przeglądarki od podstaw, podarował konkurencji trzy lata. Trzy mocne punkty po stronie naprawy:

Spolsky pisał to ćwierć wieku temu, czyli przed open source na taką skalę, jaką znamy dziś, przed gotowymi klockami w stylu Supabase, Auth.js, Sanity, przed darmowymi managed bazami danych. W praktyce: dziś przepisanie często wychodzi taniej niż utrzymywanie starego kodu, jeśli ten kod faktycznie jest na tyle zły, że każda zmiana psuje coś innego.

Najważniejsze: przepisanie nie musi być wielkim wybuchem. Sprawdzony wzorzec to Strangler Pattern, czyli figowiec dusiciel. Nowy system stoi obok starego, a ruch przekierowywany jest po jednej trasie naraz. Gdy wszystko jest przeniesione, stary serwer się wyłącza. Bez wielkiego dnia, w którym wszystko musi zadziałać.

Naprawiaj, jeśli:

Przepisuj od zera, jeśli:

Najczęstszy zdrowy scenariusz to hybryda: zaczynasz od audytu, ustalasz, co przepisać, co poprawić, i robisz to etapami. Budżet jest niższy niż big bang, czas trwania dłuższy, ale ryzyko zatrzymania biznesu praktycznie zero.

Dwa konkretne przykłady z naszego portfolio. Oba różne, oba pokazują inną stronę tego problemu.

Centrum Medycyny Zapobiegawczej i Rehabilitacji to przychodnia prowadzona przez Fundację Instytut Profilaktyki Zakażeń. Fundacja trafiła do nas w sytuacji, którą znamy z dziesiątek rozmów z organizacjami non-profit: strona przychodni stała na WordPressie, była niedokończona, działała bez certyfikatu SSL, a freelancer, który zaczął nad nią pracować, w pewnym momencie przestał odbierać wiadomości. To częsty scenariusz, szczególnie przy mniejszych projektach: ktoś bierze zlecenie, robi 60 procent pracy, znika, a klient zostaje z kodem, którego nie ma kto dokończyć.

Diagnoza była jednoznaczna. Bez SSL nie da się legalnie zbierać żadnych danych, nawet kontaktowych. Niedokończony WordPress oznaczał, że każda próba edycji groziła rozsypaniem strony. Postawiliśmy nową witrynę w React z Sanity jako CMS-em. React dał szybkość i interaktywność, Sanity zapewnił ekipie fundacji wygodny panel do publikacji bez konieczności wracania do programisty. SSL od pierwszego dnia, hosting na stabilnej infrastrukturze, pełny kod przekazany klientowi w jego repozytorium.

Fundacja Znajdki prowadzi schroniska dla psów i kotów. Sytuacja wyjściowa była podobna do tej z poprzedniego przykładu: porzucona strona po freelancerze, utrudniony kontakt z autorem kodu i poczucie, że nikt nie weźmie ich projektu w pełną opiekę. Tyle że ich potrzeba szła dalej niż "potrzebujemy mieć stronę, która działa".

Sercem problemu była ekonomia zbiórek. Każda popularna platforma do crowdfundingu pobiera prowizję od wpłat. Co ważniejsze, anonimizuje dane darczyńców. Fundacja widziała tylko kwotę i datę, bez kontaktu do osoby, która tę wpłatę wykonała. To znaczyło realnie: brak możliwości podziękowania imiennie, brak relacji z darczyńcą, brak budowania społeczności wokół fundacji, brak szansy na ponowienie kontaktu przy kolejnej zbiórce. Każda wpłata była jednorazową transakcją zamiast początku relacji.

Postawiliśmy pełną stronę fundacji w React i Sanity, z wbudowanym systemem zbiórek opartym o PayU. Wpłaty trafiają bezpośrednio na konto Znajdek, bez pośrednika i bez prowizji platformy crowdfundingowej. Dane darczyńców (zgodnie z RODO, z jasnymi opt-inami) zostają w bazie fundacji. Efekt operacyjny jest prosty: każda złotówka idzie tam, gdzie powinna, a fundacja ma narzędzie do budowania długoterminowych relacji z ludźmi, którzy chcą jej pomagać.

Nie ma jednej odpowiedzi. Cena migracji zależy od kilku rzeczy: ile jest stron i typów treści, w jakim stanie jest baza danych, czy są testy, czy są integracje z zewnętrznymi systemami, czy klient ma już zespół, który zrobi część pracy. Zamiast podawać konkretne kwoty, które prawie zawsze rozjeżdżają się z rzeczywistością, opiszemy widełki, w jakich się zwykle mieścimy.

Strona wizytówkowa, do pięciu typów treści, prosta struktura. Typowo dwa do czterech tygodni pracy, z audytem na początku i przeniesieniem treści. Mieści się w tym przebudowa frontendu, nowy CMS (zwykle Sanity), redirecty z poprzednich URLi, podstawowa zgodność z RODO i WCAG.

E-commerce albo strona z blogiem, kilkanaście typów treści, integracje. Sześć do dziesięciu tygodni. Tu dochodzi praca z bazą danych, struktura kategorii, integracja z systemem płatności, mapowanie SEO. Część projektu to przeniesienie istniejących klientów na nową stronę bez utraty pozycji w Google.

Aplikacja internetowa z modułem logowania, panelem klienta i integracjami. Cztery do sześciu miesięcy, w etapach. Rzadko robimy to jako jedną ofertę, częściej dzielimy projekt na fazy, każda z własnym budżetem i z czymś, co działa po jej zakończeniu. Strangler Pattern w praktyce: nowy moduł obok starego, przeniesienie ruchu po jednym fragmencie naraz.

W każdym z tych scenariuszy kluczowe jest, żeby przed wyceną zrobić audyt. Bez niego liczby są zgadywaniem, a różnica między dobrze a źle wycenionym projektem to często sześćdziesiąt procent budżetu.

Jeśli szukasz wykonawcy nowej strony lub aplikacji, warto zwrócić uwagę na kilka rzeczy. Lista nie jest sztywną listą wymagań, a raczej zestawem obserwacji z naszej praktyki. Trzy lub więcej punktów zaznaczonych na "tak" zwykle oznacza, że warto poszukać dalej.

Nie każdy freelancer jest słaby. Wielu jest świetnych. Ale każdy z powyższych punktów to sygnał, który warto sobie zaznaczyć i rozumieć, co bierzesz na siebie.

Jeśli rozpoznajesz coś z powyższego we własnej sytuacji, nie jesteś sam. Większość firm, z którymi zaczynaliśmy współpracę, była w punkcie wyjścia bardzo podobnym do twojego. Da się to ogarnąć, czasem w tygodnie, czasem w miesiące. Najtrudniejsze jest zwykle pierwsze pytanie: od czego zacząć?

Trzy ścieżki, w zależności od tego, gdzie aktualnie jesteś.

Najszybciej zacząć od audytu. Sprawdzamy stronę pod kątem wydajności, SEO, bezpieczeństwa, zgodności z WCAG i RODO. Konkretny raport, bez ogólników.

Zobacz konsultacje techniczne.

Jeśli decyzja o migracji jest podjęta, najszybciej zerknąć na stronę modernizacji. Opisaliśmy tam nasz proces, stack i sposób, w jaki układamy etapy projektu, żeby ryzyko było pod kontrolą.

Zobacz modernizację stron i aplikacji.

Krótka rozmowa, twoja strona i nasze obserwacje. Bez zobowiązań i bez handlowca przy słuchawce.

Napisz przez formularz kontaktowy.

Niezależnie od tego, którą ścieżkę wybierzesz, pierwszy krok jest ten sam: ktoś po naszej stronie patrzy na twoją stronę, mówi, co znalazł, i dopiero potem rozmawiamy o tym, co dalej.