Patryk KorzeniowskiTL;DR
Jeśli masz 90 sekund: naprawiaj, jeśli kod ma TypeScript, aktualny framework, rozsądną bazę i mniej niż 30 tys. linii. Przepisuj od zera (Strangler Pattern, nie big bang), jeśli kod jest starszy niż 5 lat, bez testów i bez kontaktu z autorem. Realne budżety: od 113 tys. PLN za migrację WordPressa po 528 tys. za przepisanie systemu rezerwacji dla sieci klinik. Zwrot inwestycji: 6-18 miesięcy, pod warunkiem że Core Web Vitals i SEO faktycznie się poprawią.
Reszta artykułu to liczby, źródła i framework decyzyjny. Jeśli czytasz dalej, prawdopodobnie jesteś w tej sytuacji albo właśnie dostałeś taką wycenę i chcesz wiedzieć, czy jest uczciwa.
Dostałeś stronę od freelancera za 15 tysięcy złotych. Miała być "nowoczesna, responsywna, szybka". Po roku okazuje się, że Google jej nie widzi, ładuje się 6 sekund na telefonie, a formularz kontaktowy nie wysyła maili od trzech miesięcy. Idziesz do software house'u i słyszysz: "Poprawienie tego kosztuje 80 tysięcy. Albo przepisujemy od zera za 120."
Co jest grane?
Ten artykuł powstał, żeby odpowiedzieć na to pytanie konkretnie, z liczbami i źródłami. Nie po to, żeby Cię przestraszyć, ale żeby dać Ci narzędzia do podjęcia dobrej decyzji. Bo jeśli czytasz ten tekst, prawdopodobnie jesteś w jednej z dwóch sytuacji: albo właśnie dostałeś taką wycenę i chcesz zrozumieć, czy jest uczciwa, albo czujesz, że coś jest nie tak z Twoją stroną i zastanawiasz się, co dalej.
Obie sytuacje są normalne. Większość klientów, z którymi rozmawiamy, zaczyna dokładnie w tym samym miejscu.
Dlaczego to w ogóle tyle kosztuje
Stawki na polskim rynku IT w 2025 roku
Zacznijmy od kontekstu. Ile kosztuje godzina pracy programisty w Polsce?
Freelancerzy (dane z Useme, LinkedIn, 4programmers):
- Junior: 80-120 PLN/h
- Mid: 120-200 PLN/h
- Senior: 200-350 PLN/h
Software house'y (dane z Digitay, PolDevs, 4programmers):
- Junior w zespole: 150-220 PLN/h
- Mid: 220-350 PLN/h
- Senior: 350-500 PLN/h
- Architekt / Tech Lead: 500-700 PLN/h
- Day rate (8h): 1 200-4 000 PLN
Źródła: No Fluff Jobs, CRN.pl, Digitay, PolDevs.
Dlaczego software house jest droższy na godzinę? Bo w tej stawce jest zespół: programista, ale też ktoś kto sprawdza jego kod (code review), ktoś kto testuje (QA), ktoś kto wdraża na serwer (DevOps), ktoś kto pilnuje harmonogramu (PM). Plus umowa z przeniesieniem praw autorskich, NDA, ciągłość pracy gdyby ktoś zachorował. Freelancer pracuje sam. Jeśli zniknie, zostajesz z kodem, którego nikt inny nie zna.
Tylko 16% projektów IT kończy się na czas i w budżecie
To nie jest straszenie. To dane z raportu Standish Group (CHAOS Report), potwierdzane od 1994 roku do dziś:
- 16% projektów kończy się on-time i on-budget
- 52,7% projektów przekracza budżet, średnio o 189% pierwotnej wyceny
- 31% projektów jest anulowanych przed ukończeniem
- Małe projekty mają ~90% szans powodzenia. Duże (powyżej 10 mln) poniżej 10%
Źródła: Standish Group CHAOS, BCG 2024.
Co z tego wynika? Jeśli planujesz przepisanie strony od zera, tnij projekt na kawałki krótsze niż 3 miesiące. Statystycznie, mniejsze projekty kończą się sukcesem.
Co zwykle znajdujemy w audycie
Kiedy klient przychodzi do nas z prośbą o ocenę strony po freelancerze, robimy audyt kodu. To 8-40 godzin pracy, zależnie od wielkości projektu. Poniżej lista tego, co znajdujemy najczęściej. Nie każdy projekt ma wszystkie te problemy, ale każdy projekt ma co najmniej połowę z nich.
Top 5 problemów, które widzimy w 80% audytów:
1. Strona niewidoczna dla Google (brak SSR)
Freelancer zbudował stronę w React (Create React App albo Vite). Wygląda ładnie w przeglądarce. Problem: gdy Googlebot odwiedza taką stronę, widzi pusty HTML: <div id="root"></div> i nic więcej.
Google potrafi renderować JavaScript, ale robi to w dwóch falach. Pierwsza fala to sam HTML. Druga fala, rendering JS, trafia do kolejki. Mediana czekania to 5 sekund, ale w praktyce nowe strony mogą czekać godziny, dni, a czasem tygodnie. Badania Onely pokazują, że 5-50% nowo dodanych stron pozostaje niezindeksowanych po 2 tygodniach od dodania do sitemap.
A crawlery AI (GPTBot, ClaudeBot, PerplexityBot)? Te w ogóle nie renderują JavaScriptu. Jeśli chcesz być cytowany w ChatGPT, Perplexity czy Google AI Overviews, potrzebujesz gotowego HTML z serwera.
Źródła: Onely, CapConvert.
2. "SSR na czuja" w czystym Reakcie
Niektórzy freelancerzy próbują robić server-side rendering samodzielnie, na Express.js z renderToString. Teoretycznie działa. W praktyce brakuje:
- Streamingu (serwer musi wyrenderować wszystko, zanim wyśle cokolwiek)
- Prawidłowej hydracji (błędy w konsoli, mismatch między HTML a JS)
- Code splittingu per route (jeden wielki plik JS dla całej strony)
- Cache na poziomie CDN (każdy request renderuje od nowa na serwerze)
- Metadanych per route (jedne meta tagi dla całej aplikacji)
- Poprawnych statusów HTTP (404 dla nieistniejących stron zwraca 200)
- Danych strukturalnych JSON-LD w HTML
Next.js rozwiązuje każdy z tych punktów natywnie. Dlatego właśnie istnieje.
3. Brak TypeScriptu
W 2026 roku 4 na 5 frontendowych projektów ma TypeScript. Brak TS to czerwona flaga, którą widać z daleka.
Najprościej tłumacząc: bez TypeScriptu każda zmiana w kodzie to loteria. Zmieniasz nazwę pola w API, a trzy komponenty się psują, bo nikt Ci nie powiedział, że ich też używają. TypeScript łapie to automatycznie, jeszcze zanim uruchomisz stronę. Programista oszczędza tygodnie debugowania, Ty oszczędzasz miesiące czekania na poprawki.
Dodanie TypeScriptu do istniejącej aplikacji JavaScript (20-40 tys. linii kodu): 80-200 godzin pracy, 30-80 tys. PLN.
4. Brak testów
Żadnych testów. Ani jednostkowych, ani integracyjnych, ani end-to-end. Każda zmiana wymaga ręcznego przeklikania całej strony. Dopisanie testów po fakcie kosztuje 20-40% czasu, jaki zajęło napisanie kodu.
5. Deploy przez FTP
Freelancer wrzuca pliki na serwer przez FTP albo robi git pull na produkcji. Brak CI/CD oznacza:
- Brak automatycznych testów przed wdrożeniem
- Brak środowiska preview/staging do testowania
- Brak automatycznego rollbacku gdy coś pójdzie nie tak
- Każdy deploy to ręczna operacja z ryzykiem pomyłki
Poprawny setup GitHub Actions + Coolify + automatyczne migracje bazy danych: 8-24 godziny, 2-8 tys. PLN. Raz.
Pozostałe 6 problemów (rzadziej, ale poważnie):
6. Niezabezpieczone API
Endpointy API bez autoryzacji. /api/admin/users dostępne bez tokena. /api/orders/123 pokazuje cudze zamówienia (IDOR). Brak ochrony CSRF w formularzach. Brak rate limitingu, więc ktoś jednym skryptem może wysłać 10 000 wiadomości przez Twój formularz kontaktowy w 5 minut.
Dla podmiotów objętych dyrektywą NIS2 (sektor zdrowia, energetyka, transport, infrastruktura cyfrowa) to nie jest opcjonalne. Każdy z tych braków to potencjalne naruszenie obowiązku zarządzania ryzykiem cyberbezpieczeństwa, a kary sięgają 10 mln EUR lub 2% rocznego obrotu.
7. Hardcoded klucze API
Klucz Stripe w kodzie klienckim. Hasło SMTP w repozytorium. Git history pełen commitów "oops, usuwam klucz". (Klucz nadal jest w historii gita. Trzeba go unieważnić i wygenerować nowy.)
8. Brak dostępności (a11y)
Brak aria-label na przyciskach. Kontrast tekstu nie spełnia WCAG AA. Formularze bez <label>. Modal nie pułapkuje focusa, więc osoba korzystająca z klawiatury utknęła.
To nie jest "miło mieć". Europejski Akt o Dostępności (EAA) obowiązuje od 28 czerwca 2025. E-commerce, bankowość, transport, rezerwacje online muszą być zgodne. Kary za naruszenia są realne.
A jeśli prowadzisz klinikę? EAA dotyczy każdego systemu rezerwacji online. Pacjent z niedowidzeniem, który nie może umówić wizyty, może zgłosić to do UODO i Rzecznika Praw Pacjenta. Jeśli Twoja strona ma formularz rezerwacji, jesteś objęty regulacją. Bez wyjątków.
9. RODO na życzenie
Brak cookie banneru z prawdziwym opt-in. Google Analytics ładowane od razu, bez czekania na zgodę. Polityka prywatności skopiowana z internetu. Brak umów powierzenia danych z dostawcami. Pełną listę wymogów RODO/GDPR trzymamy osobno, bo zmienia się szybko.
Kontekst: w 2024 roku UODO nałożyło 14 mln PLN kar. To 10 razy więcej niż rok wcześniej. Polska jest na 3. miejscu w Europie pod względem zgłoszonych naruszeń (14 286 przypadków). Najwyższa kara w Polsce: 4,9 mln PLN (Fortum). Maksymalna kara RODO: do 20 mln EUR lub 4% rocznego obrotu.
Źródła: Grant Thornton, GDPR.pl.
10. Zła architektura bazy danych
Brak indeksów na kolumnach używanych w zapytaniach. Problem N+1: widok listy pobiera każdy rekord osobnym zapytaniem (200 zapytań na jeden render strony). Zmiany w bazie robione ręcznie w phpMyAdmin, bez migracji. SELECT * w każdym endpointcie, nawet gdy potrzebujesz 2 z 40 kolumn.
11. Brak monitoringu
Brak Sentry, brak logów strukturalnych. Błąd na produkcji? Klient dzwoni i mówi "nie działa". Koniec diagnozy. Setup Sentry (darmowy plan) + podstawowe logi: 4-12 godzin, 1-4 tys. PLN. Raz.
Dlaczego Twoja strona nie rankuje (i co z tym zrobić)
Jak Google crawluje strony zbudowane w JavaScript
Google renderuje strony w dwóch falach:
Fala 1: Googlebot pobiera HTML. Jeśli strona to React SPA, widzi pusty <div>. Zapisuje. Idzie dalej.
Fala 2: HTML trafia do Web Rendering Service, kolejki opartej na Chrome headless. Dopiero tam JavaScript się wykonuje i Google widzi treść.
Problem: ta kolejka nie jest natychmiastowa. Mediana to 5 sekund, ale dla nowych stron bywa to dużo dłużej. Googlebot ma też twarde limity: 2 MB na plik, brak scrollowania, timeout dla asynchronicznych operacji. Jeśli Twój JavaScript ładuje dane z API po załadowaniu strony, Googlebot może tego nie zobaczyć.
Crawlery AI (GPTBot, ClaudeBot, PerplexityBot) nie renderują JavaScriptu w ogóle. Jeśli Twoja strona jest SPA, dla tych botów po prostu nie istnieje.
Źródła: Onely, Vercel Research, CapConvert.
Core Web Vitals w liczbach
Google mierzy trzy wskaźniki wydajności (Core Web Vitals): LCP (jak szybko pojawia się główna treść), INP (jak szybko strona reaguje na kliknięcie), CLS (czy elementy przeskakują podczas ładowania).
Stan w 2025:
- Tylko 48% stron mobilnych zdaje wszystkie trzy wskaźniki
- LCP to najtrudniejszy: tylko 62% stron mobilnych ma dobry wynik
- 87% amerykańskiego e-commerce nie zdaje Core Web Vitals
- Średni LCP na mobile w B2B: 7,05 sekundy (cel: poniżej 2,5s)
Źródła: corewebvitals.io, Huckabuy.
Co daje Next.js (i dlaczego budujemy na nim)
Trzy warianty strony w React, od najgorszego:
React SPA (Create React App / Vite): HTML pusty, cały JS buduje stronę w przeglądarce. Googlebot czeka na rendering. LCP 5-10 sekund na mobile to norma.
SSR w czystym React (Express + renderToString): HTML gotowy, ale bez streamingu, bez cache, bez code splittingu per route, bez metadanych per route.
Next.js App Router: rozwiązuje powyższe problemy natywnie:
- React Server Components domyślnie. Komponenty renderują się na serwerze, zero JavaScript po stronie klienta dla komponentów serwerowych.
- Streaming przez Suspense. Serwer wysyła gotowy kawałek HTML od razu. Dynamiczne części dolatują w tle. Użytkownik widzi treść natychmiast.
- Partial Prerendering (PPR). Statyczna "powłoka" serwowana z CDN, dynamiczne elementy streamowane z serwera. Jedno żądanie HTTP, minimalne opóźnienie.
- ISR (Incremental Static Regeneration). Zbuduj raz, odświeżaj w tle co godzinę. Szybkość statycznej strony z aktualnością dynamicznej.
- Metadata API. Metadane (title, description, OG image) per route, w kodzie, renderowane na serwerze. Googlebot widzi je od razu.
- Automatyczny sitemap.xml, robots.txt, dane strukturalne JSON-LD. Bez dodatkowych wtyczek.
Źródła: Next.js Server Components, Next.js PPR.
Realne wyniki migracji
To nie teoria. Przykłady z ostatnich dwóch lat:
- Panda Patches (WooCommerce na Next.js): zero spadków w Search Console, obrót $38k/mc przy kosztach hostingu $25/mc. Vercel Community
- Retail, 600 stron (WordPress na Next.js): LCP z 4,2s do 0,8s, konwersje +27%. Medium
- Swappie: LCP -55%, CLS -91%, FID -90%, przychód mobile +42%. wpostats
- Rakuten 24: przychód na odwiedzającego +53,4%, konwersja +33,1%. wpostats
- Zalando: każde 100ms szybciej to +0,7% przychodu. wpostats
Z naszego podwórka
Najlepiej znamy te liczby z własnych produktów. Kiedy budowaliśmy harmonogramslubow.pl od zera w Next.js zamiast iść klasyczną drogą "WordPress + wtyczka kalendarza", wystartowaliśmy z gotowym SSR, zerową konfiguracją cache i pełną zgodnością WCAG od dnia pierwszego. Efekt: aplikacja indeksuje się w Google w 48h zamiast tygodni, ładuje się poniżej sekundy na mobile i nie wymaga miesięcznej opieki "żeby coś nie padło". Tę samą architekturę stawiamy klientom, którzy migrują z WordPressa albo SPA.
Naprawić czy przepisać od zera?
To najtrudniejsza decyzja w tym procesie. Zanim podejmiesz ją intuicyjnie, warto znać argumenty obu stron. Jeśli chcesz od razu zobaczyć jak to robimy w praktyce, mamy osobną stronę o modernizacji istniejących systemów. Tu rozkładamy decyzję na czynniki pierwsze.
Argument za naprawianiem
Inżynierowie kłócą się o to od 25 lat, ale klasyczny argument przeciwko przepisywaniu od zera pochodzi od Joela Spolsky'ego, współtwórcy Stack Overflow. Krótka wersja: kiedy Netscape przepisał swoją przeglądarkę od zera, zniknął z rynku na 3 lata. W tym czasie Internet Explorer zjadł im użytkowników i Netscape już nigdy się nie podniósł.
Trzy mocne argumenty:
- Stary kod zawiera setki drobnych poprawek na realne błędy. Wyrzucasz go, wyrzucasz tę wiedzę.
- Kod jest trudniejszy do czytania niż do pisania. To, że wygląda źle, nie znaczy, że jest zły.
- Podczas przepisywania nie możesz rozwijać produktu. Konkurencja Cię wyprzedza.
Źródło: Joel on Software.
Argument za przepisaniem
Tyle że Spolsky pisał to w 2000 roku, czyli przed erą open source, serverless i gotowych klocków. Dziś przepisanie często wychodzi taniej niż utrzymywanie archaicznego kodu, zwłaszcza gdy technologia jest zupełnie inna (np. jQuery SPA z 2015 roku do nowoczesnego React).
Najważniejsze: przepisanie nie musi być "wielkim wybuchem". Sprawdzona metoda nazywa się Strangler Pattern (od strangler fig, czyli figowca dusiciela): nowy system stoi obok starego, a żądania użytkowników po jednym przenosi się ze starego na nowy. Z czasem stary system zostaje "uduszony" i wyłączony.
W kontekście Next.js: stawiasz nowy frontend, w konfiguracji ustawiasz reguły przekierowań. Migrujesz po jednej trasie. Gdy wszystko jest przeniesione, wyłączasz stary serwer. Bez "wielkiego wdrożenia" w weekend.
Źródła: Joel on Software, Strangler Fig Pattern.
Kiedy naprawiać, kiedy przepisywać?
Naprawiaj, jeśli:
- Jest TypeScript (nawet fragmentarycznie)
- Framework jest aktualny (React 18+, Node 20+)
- Baza danych jest sensowna (relacyjna, z migracjami)
- Problemy są punktowe (SEO, wydajność, konkretny moduł)
- Kod ma poniżej 30 tys. linii i da się go czytać
- Ktoś, kto go napisał, jest kontaktowy, albo istnieje dokumentacja
Przepisuj od zera, jeśli:
- JavaScript bez TypeScriptu, powyżej 15 tys. linii kodu
- WordPress z 30+ wtyczkami
- Framework starszy niż 5 lat (AngularJS, jQuery SPA)
- Brak testów + brak dokumentacji + brak kontaktu z autorem
- Architektura monolityczna, gdzie każda zmiana rusza 5 niezwiązanych funkcji
- Hardcoded sekrety w historii gita, brak autoryzacji, podatności z OWASP Top 10
- Baza bez migracji, bez normalizacji, SELECT * wszędzie
- Dług techniczny zjada ponad 60% czasu każdej zmiany
Heurystyka kosztu: jeśli miesięczny koszt utrzymania (bug fixy + aktualizacje security + downtime + frustracja) przekracza 10-15% kosztu przepisania, rewrite zwraca się w rok.
Najczęstszy zdrowy scenariusz: hybrid. Strangler Pattern. Nowy system obok starego, rewrite moduł po module. Budżet o 30-40% niższy niż big bang, ale 30-50% dłuższy w czasie.
Trzy scenariusze z realnymi liczbami
Scenariusz 1: "WordPressowy dług" (średni projekt)
Sytuacja: e-commerce B2B. WordPress + WooCommerce, 300 produktów, blog ze 120 wpisami, 25 wtyczek. Strona ładuje się 6,8 sekundy na mobile. Core Web Vitals: niezdane. Konwersja: 0,8% (mediana branżowa to 2%). Freelancer chce 2 000 PLN/mc za "utrzymanie".
Diagnoza: Elementor Pro + 6 wtyczek SEO + 3 wtyczki cache walczące ze sobą. PageSpeed: 31 na mobile.
Plan: WordPress zostaje jako headless CMS (dla osób z marketingu). Frontend na Next.js App Router. Hosting: Hetzner + Coolify. Obrazy na S3-compatible storage. Blog i produkty jako ISR (odświeżanie co godzinę). Checkout: Stripe + custom API.
Budżet:
| Etap | Godziny | Koszt |
|---|---|---|
| Audyt + plan migracji | 40h | 12 tys. PLN |
| Frontend Next.js (15 szablonów, 8 typów treści) | 240h | 72 tys. PLN |
| Migracja 420 URLi z mapowaniem redirectów | 32h | 9,6 tys. PLN |
| Infrastruktura (Coolify, backup, monitoring) | 24h | 7,2 tys. PLN |
| QA + UAT | 40h | 12 tys. PLN |
| Razem | 376h | ~113 tys. PLN, 10 tygodni |
Oczekiwany efekt (3 miesiące po wdrożeniu):
- PageSpeed: 31 na 94 (mobile)
- LCP: 6,8s na 1,1s
- Core Web Vitals: zdane
- Konwersja: 0,8% na 1,9-2,4%
- Hosting: 650 PLN/mc na 60 PLN/mc
- Zwrot inwestycji: 6-10 miesięcy przy podwojeniu konwersji
Scenariusz 2: "SPA, które nie rankuje" (duży projekt)
Sytuacja: SaaS B2B (CRM dla agencji nieruchomości). React SPA zbudowany w Vite + React Router + własny backend w Node.js. Landing page, dokumentacja i blog, wszystko w jednej aplikacji SPA. Zero ruchu organicznego mimo 40 wpisów blogowych. Google widzi puste strony.
Diagnoza:
- Cały marketing site w SPA. Googlebot czeka na JS render, często nie doczekuje się.
- Metadane ustawiane przez
document.titlew useEffect. Niewiarygodne dla Google. - Brak sitemap.xml, robots.txt, danych strukturalnych.
- Bundle JS: 4,2 MB. LCP: 8 sekund.
Plan: Przepisanie części publicznej (landing, docs, blog, pricing, case studies, kontakt) na Next.js App Router z PPR. Aplikacja (panel za logowaniem) zostaje jako SPA, ale montowana w Next.js pod /app/*. Backend: migracja na Supabase (auth + Postgres + storage), z warstwą abstrakcji.
Budżet:
| Etap | Godziny | Koszt |
|---|---|---|
| Audyt | 48h | 14,4 tys. PLN |
| Next.js: marketing site + blog + docs | 200h | 60 tys. PLN |
| Integracja z istniejącym SPA | 80h | 24 tys. PLN |
| Migracja backend na Supabase | 160h | 48 tys. PLN |
| Monitoring + CI/CD | 32h | 9,6 tys. PLN |
| Razem | 520h | ~156 tys. PLN, 14 tygodni |
Oczekiwany efekt:
- Google Search Console: 0 na 40+ zindeksowanych stron w 2 tygodnie
- Ruch organiczny w 3-6 miesięcy: 500-2 000 sesji/mc
- LCP: 8s na 0,9s
- Hosting: z ~800 PLN/mc na ~60 PLN/mc
Scenariusz 3: "Trzeba to wyrzucić" (bardzo duży projekt)
Uwaga: to przypadek brzegowy, około 5% projektów które do nas trafiają. Większość klientów mieści się w scenariuszach 1 i 2. Pokazujemy go, żeby było jasne, gdzie biegnie górna granica i kiedy rewrite faktycznie ma sens.
Sytuacja: sieć klinik prywatnych (8 placówek). System rezerwacji wizyt online + portal pacjenta + integracja z gabinetem napisane przez freelancera za 30 tys. PLN. Po 8 miesiącach nie da się dodać nic nowego. Każda zmiana psuje 3 inne rzeczy. Freelancer zniknął. 400 plików JavaScript bez TypeScriptu. Monolityczny Node.js z Firebase Firestore. Frontend na Create React App. Brak testów, brak dokumentacji. Produkcja wiesza się dwa razy w miesiącu, a pacjenci tracą terminy wizyt.
Diagnoza:
- Dług techniczny: ~80%. Każda godzina developmentu to 45 minut debugowania.
- Security: Firebase Admin SDK key w repozytorium. Brak rate limitingu. Dane medyczne pacjentów bez szyfrowania at-rest.
- Compliance: brak zgodności z RODO (dane medyczne to art. 9, szczególna kategoria). Brak audytu WCAG (od czerwca 2025 obowiązkowo dla rezerwacji online, zgodnie z Europejskim Aktem o Dostępności).
- Firebase: $800/mc przy 2 000 pacjentów aktywnych. Firestore reads bez indeksów.
- Nie da się tego audytować, bo nie ma testów.
Decyzja: Rewrite od zera, Strangler Pattern. Parallel run 4 miesiące. Inaczej kara RODO za pierwszy poważny incident może przekroczyć cały koszt przepisania.
Plan: Nowy stack, moduł po module: auth, kalendarz wizyt, portal pacjenta, panel lekarza, raporty. Stary system dostępny pod oddzielną domeną dla obecnych użytkowników. Nowi pacjenci na nowym systemie. Migracja danych w jednym weekendzie na koniec.
Budżet:
| Etap | Godziny | Koszt |
|---|---|---|
| Discovery + architektura | 80h | 24 tys. PLN |
| Core platform (auth, pacjenci, kalendarz) | 400h | 120 tys. PLN |
| Logika biznesowa (rezerwacje, portal pacjenta, integracja gabinet) | 800h | 240 tys. PLN |
| Panel lekarza + administracyjny | 200h | 60 tys. PLN |
| DevOps + monitoring | 80h | 24 tys. PLN |
| QA + audyt bezpieczeństwa + WCAG + RODO | 120h | 36 tys. PLN |
| Migracja danych + parallel run | 80h | 24 tys. PLN |
| Razem | 1 760h | ~528 tys. PLN, 6 miesięcy |
Dla porównania: gdyby klient próbował to naprawiać, 120h/mc razy 12 miesięcy razy 300 PLN/h = 432 tys. PLN sam maintenance. Plus bug fixy. Plus koszt straconych pacjentów (każda awaria rezerwacji = pacjent idzie do konkurencji). Plus realne ryzyko kary RODO za naruszenie danych medycznych (do 20 mln EUR). Rewrite tańszy w perspektywie 18 miesięcy.
Ukryte koszty, o których nikt nie mówi
Twój czas jako właściciela
Meetings: 2-4 godziny tygodniowo przez 3-6 miesięcy. Jeśli Twoja stawka realna (opportunity cost) to 300-500 PLN/h, to 12-50 tys. PLN nieujętych w żadnej wycenie. Plus testy akceptacyjne (20-60h). Plus setki decyzji "tak albo nie" wysyłanych mailem.
Stracony ruch z Google
Brak SSR oznacza, że Google Twojej strony nie widzi. Dla firmy B2B z 10 leadami miesięcznie o wartości 5 tys. PLN, strata 30% ruchu organicznego to 15 tys. PLN miesięcznie. 180 tys. PLN rocznie. Niewidocznych, bo nigdy się nie pojawiły w CRM.
Kilka liczb o wpływie prędkości na pieniądze:
- Amazon: każde 100ms opóźnienia = -1% sprzedaży
- Walmart: każda sekunda szybciej = +2% konwersji
- Deloitte: 0,1s poprawy na mobile = +8,4% konwersji w retail
- Google: prawdopodobieństwo opuszczenia strony rośnie o 32% gdy ładowanie idzie z 1s do 3s, o 90% przy 5 sekundach
- 53% użytkowników mobile opuszcza stronę ładującą się ponad 3 sekundy
Źródła: GlobalDots, Mantasdigital.
Hosting, który zjada budżet
Porównanie kosztów rocznych:
| Hosting | Koszt miesięczny | Rocznie |
|---|---|---|
| Vercel Pro (5 osób, średni ruch) | $100-500/mc | $1 200-6 000 |
| Managed WordPress (dużo ruchu) | $200-1 000+/mc | $2 400-12 000 |
| Hetzner + Coolify (self-hosted) | €4-15/mc | €50-180 |
Vercel nalicza $0,15 za każdy GB ponad 1 TB. Hetzner daje 20 TB w cenie. To 4000% markup na bandwidthcie.
Realny przykład: klient z Vercel za $850/mc przeniósł się na Coolify + Hetzner za $14/mc. 37signals (Basecamp/HEY) zaoszczędziło $7 mln w 5 lat po wyjściu z chmury.
Źródła: Leon Consulting, MassiveGRID, Temps.sh.
Uczciwe zastrzeżenie: self-hosting to nie jest "za darmo". Wymaga wiedzy. W styczniu 2026 ujawniono 11 krytycznych podatności w Coolify (3 z CVSS 10.0), obejmujących 52 890 publicznych instancji. Self-hosting skonfigurowany przez software house to inny poziom niż "zrób sobie sam". Ale oszczędność jest realna.
Kary RODO
W 2024 roku UODO nałożyło kary o łącznej wartości 14 mln PLN. Najwyższa: 4,9 mln PLN. Brak szyfrowania dysków i utrata pendrive'a: 238 tys. PLN. Niezgłoszenie naruszenia w ciągu 72 godzin: 21 tys. PLN.
Dla porównania: kompleksowe wdrożenie zgodności z RODO na stronie kosztuje 5-15 tys. PLN. Kara za jej brak może być 100 razy wyższa.
Jak nie wpaść w tę sytuację ponownie
Jeśli szukasz wykonawcy nowej strony lub aplikacji, oto lista sygnałów ostrzegawczych:
- Brak portfolio z żywymi stronami. "Zrobiłem dla klienta X, ale nie mogę pokazać" to czerwona flaga.
- Brak repozytorium, do którego masz dostęp. Kod powinien być Twój od pierwszego commita.
- Brak umowy z przeniesieniem praw autorskich. Bez tego kod technicznie należy do freelancera.
- Bardzo niska cena. Poniżej 100 PLN/h? Albo junior bez doświadczenia, albo outsource do Azji bez Twojej wiedzy.
- "Nie potrzebujemy testów." Testy to nie luksus. To minimum profesjonalizmu.
- Brak propozycji architektury przed pisaniem kodu. Profesjonalista nie zaczyna od klawiatury.
- Wszystko robi sam. Bez designera, QA, code review. Jeden człowiek nie pokryje wszystkich kompetencji.
- Deploy? "Tym zajmie się admin." Programista, który nie wie jak wdrożyć swój kod, nie skończył swojej pracy.
- Hasła przesyłane przez WhatsApp zamiast trzymane w password managerze.
Nie każdy freelancer jest zły. Wielu jest świetnych. Ale jeśli widzisz 3 lub więcej z powyższych punktów, szukaj dalej.
Jak to robimy w EPKO
Nie piszemy tego artykułu, żeby powiedzieć "freelancerzy źli, software house'y dobre". Piszemy go, bo wiemy jak wygląda sytuacja od środka. Większość klientów, z którymi rozmawiamy, przychodzi po dokładnie takim doświadczeniu.
Nasz stack technologiczny:
- Next.js App Router (React Server Components, PPR, ISR)
- Supabase (PostgreSQL + Auth + Storage) lub .NET po stronie backendu
- TypeScript strict, bez wyjątków
- Tailwind CSS + Radix UI (dostępność, ciemny/jasny motyw)
- Docker + Coolify na własnym serwerze dedykowanym (Hetzner; nie Vercel, nie współdzielony hosting)
- GitHub Actions (CI/CD)
Nasz proces:
- Audyt. Sprawdzamy co masz, co działa, co nie. Z konkretnymi liczbami.
- Plan. Naprawić czy przepisać? Strangler Pattern czy big bang? Z budżetem i harmonogramem.
- Realizacja. W etapach krótszych niż 3 miesiące. Z code review, testami, CI/CD.
- Wdrożenie. Z monitoringiem, backupami, alertami.
- Zostajemy. Retainer na utrzymanie i rozwój. Nie znikamy po wdrożeniu.
Rozmawiasz bezpośrednio z Patrykiem (biznes) i Erykiem (technika). Nie mamy account managera, który przekazuje dalej. Jeśli napiszesz maila z drobną zmianą, może być wdrożona tego samego dnia.
Co dalej?
Jeśli masz stronę po freelancerze i czujesz, że coś jest nie tak, to normalne. Nie jesteś jedyny. 80% klientów, z którymi rozmawiamy, zaczyna w tym samym miejscu.
Da się to naprawić. Czasem w tygodnie, czasem w miesiące, ale da się. Możesz zacząć od trzech miejsc, w zależności od tego, gdzie jesteś:
- Nie wiesz, czy Twoja strona ma problem. Zacznij od bezpłatnego audytu technicznego. 30-minutowa rozmowa, konkretny raport.
- Wiesz, że trzeba przepisać, szukasz wykonawcy. Zobacz nasze usługi i case studies z migracji, które już zrobiliśmy.
- Pracujesz w sektorze regulowanym (medycyna, kancelarie, fundacje). Mamy osobne ścieżki dla każdej z tych branż, bo wymagania są różne.
W każdym z tych przypadków pierwszy krok jest ten sam: audyt. Sprawdzamy Twoją stronę pod kątem wydajności, SEO, bezpieczeństwa i zgodności z WCAG oraz RODO. Dostajesz konkretny raport: co jest źle, co naprawić, ile to będzie kosztować, ile czasu zajmie.
Umów bezpłatny audyt techniczny strony →
Artykuł napisany przez Patryka Korzeniowskiego, CEO EPKO. Jeśli masz pytania, napisz na patryk.korzeniowski@epko.tech albo umów rozmowę przez formularz kontaktowy.
