Suchary.com po czternastu latach: co naprawdę kupiłem za 800 złotych

Co dostałem za osiemset złotych

Kiedy w 2012 roku przelewałem te 800 złotych i dostawałem dostęp do serwera, byłem przekonany, że kupuję stronę internetową. Z perspektywy czasu widzę to inaczej — dostałem typowy polski serwis z ery Web 2.0, ze wszystkimi zaletami i wszystkimi grzechami tamtych czasów. Pod maską pracował IPS CMS od iprosoft.pl, czyli polski, niszowy silnik dedykowany stronom humorystycznym, napisany w PHP 5.x z użyciem klas — co, jak na tamte czasy pisane funkcjami proceduralnie, było całkiem solidnym rozwiązaniem. Szablony obsługiwał Smarty z tą swoją charakterystyczną składnią {$variable} i {if}...{/if}, a całość trzymała się kupy bez żadnego frameworka, bez autoloadera i — co dziś brzmi wręcz egzotycznie — bez Composera.

Baza danych to MySQL (później MariaDB) na silniku MyISAM, czyli bez kluczy obcych i bez transakcji, a hasła użytkowników leżały sobie spokojnie w postaci md5() — bez soli, bez bcrypta, bez niczego, co dzisiaj traktujemy jako absolutne minimum. Frontend opierał się na jQuery 1.9 z jQuery UI, layout miał sztywną szerokość i ani śladu responsywności, bo w 2012 roku „mobile first" było jeszcze hasłem prelegentów na konferencjach, nie codziennością.

Treść, którą przejąłem, wyglądała tak: 2586 żartów i sucharów, około 170 zarejestrowanych użytkowników, blisko 5563 tagów (te akurat świetnie łapały keywordsy w Google) oraz 72 komentarze, z których większość była spamem wygenerowanym przez XRumera[1].

Pierwsza myśl po otwarciu kodu była bardzo konkretna: „nie ruszam tego". I przez następne czternaście lat dokładnie tak postąpiłem.

Czternaście lat na autopilocie

Od 2012 do 2026 roku suchary.com działały zupełnie bez mojej interwencji. Wrzuciłem kod AdSense, ustawiłem automatyczne odnawianie domeny i hostingu, po czym w zasadzie zapomniałem o istnieniu projektu — poza dwoma momentami w roku, kiedy logowałem się do AdSense po przelew. Cała moja praca nad tym serwisem w skali rocznej mieściła się w godzinie, może półtorej, a przychody utrzymywały się na poziomie około 800 złotych rocznie.

W międzyczasie świat wokół się zmieniał, a strona stała w miejscu. Google zaczął wymuszać HTTPS, przez co pozycje zaczęły się osuwać. Potem przyszło mobile-first indexing i okazało się, że serwis, który w ogóle nie miał wersji mobilnej, zaczyna być karany w wynikach wyszukiwania. Kolejnym ciosem były Core Web Vitals — nowe metryki, kolejne spadki. W tle PHP 5.x straciło oficjalne wsparcie, a kod trzymał się jedynie dzięki temu, że CyberFolks uprzejmie utrzymywał środowisko legacy.

Lista rzeczy, których nie zrobiłem, a powinienem, jest długa i nieco wstydliwa: nie wdrożyłem SSL-a, nie aktualizowałem CMS-a (zresztą producent i tak w pewnym momencie przestał go wspierać), nie zoptymalizowałem strony pod urządzenia mobilne, nie dodałem structured data ani sitemapy XML, nie założyłem bloga ani nie wystartowałem z content marketingiem. Strona traciła pozycje rok do roku, ale na tyle wolno, a przychód z AdSense utrzymywał się na tyle stabilnie, że nigdy nie zapaliła mi się lampka ostrzegawcza. Do dzisiaj uzbierało się ponad jedenaście tysięcy złotych z inwestycji rzędu ośmiuset.

Dwie nieudane próby przepisania

Oczywiście próbowałem coś z tym zrobić — nie raz.

Pierwsze podejście przyszło około 2018 roku i nosiło nazwę „przepiszę to w Django". Python, ORM, panel admina dostępny od ręki — wszystko zapowiadało się obiecująco. Napisałem modele, miałem nawet działający prototyp strony głównej, a potem życie dopomniało się o swoje: inne projekty, praca na etacie, brak energii wieczorami. Repozytorium przeleżało kilka miesięcy w stanie hibernacji, po czym umarło śmiercią naturalną.

Drugie podejście, około 2020 roku, opierało się na Wagtailu — CMS-ie zbudowanym na Django. Teoretycznie miało być mniej kodu do napisania, bo panel admina dostawałem niemal gotowy. Problem był jednak dokładnie ten sam co poprzednio: czas. Kolejne repozytorium, kolejna cicha śmierć.

Z obu tych podejść wyniosłem jedną, dość gorzką lekcję: sam, po godzinach, w rozsądnym czasie tego serwisu nie przepiszę. Rzecz nie leżała w wyborze frameworka — leżała w proporcjach. Większość pracy przy takim projekcie to żmudna, mechaniczna implementacja, a po pełnym etacie człowiek po prostu nie ma na nią paliwa.

Trzecia próba: „vibe coding" z Claude Code

Luty 2026. Podejście, które w środowisku zaczęło się przyjmować pod nazwą „vibe coding" — programista opisuje, co chce osiągnąć, a AI generuje implementację. Decyzje architektoniczne zostają po mojej stronie, ale mozolna robota w dużej mierze schodzi z moich barków.

Wyglądało to mniej więcej tak. Zaprojektowałem schemat bazy danych w Supabase (PostgreSQL), a AI napisało migracje SQL razem z triggerami, politykami RLS i funkcjami. Parsowanie 496-megabajtowego dumpa MySQL odbyło się bezpośrednio w TypeScripcie, bez żadnej pośredniej konwersji. Cała baza treści i użytkowników została zmigrowana do nowego schematu, razem z systemem głosowania, komentarzami i pełnotekstowym wyszukiwaniem opartym na PostgreSQL FTS. Frontend dostał dark mode, responsywny layout i dolną nawigację na mobile. Panel admina obsługuje moderację, bloga i reklamy. Wdrożenie oparłem na Dockerze, Hetznerze i Cloudflare.

Łącznie około czterdziestu ośmiu godzin roboczych. Koszt narzędzia: subskrypcja Claude Code (plan Max, około stu dolarów miesięcznie).

ROI w skrócie

Łączna inwestycja w zakup, hosting i domenę rozciągnięta na czternaście lat to mniej więcej 3039 złotych. Łączny przychód z AdSense zamknął się w okolicach 11 200 złotych, co daje ROI na poziomie około 269 procent, przy okresie zwrotu kapitału początkowego wynoszącym mniej więcej rok.

Pełna kalkulacja — z porównaniem do innych klas aktywów oraz wyceną serwisu przed i po remoncie — czeka w ścieżce biznesowej.

Mapa artykułów

Całość tego case study rozdzieliłem na dwie ścieżki, bo różne osoby przychodzą tu po różne rzeczy.

Ścieżka biznesowa — ROI, monetyzacja, SEO, marketing, RODO i wycena. Od szczegółowej kalkulacji zwrotu, przez strategię monetyzacji łączącą AdSense ze Stripe'em, SEO rozsiane na 2586 stronach, marketing bez budżetu, compliance zgodny z RODO, aż po wycenę serwisu w obu stanach — przed i po remoncie.

Ścieżka techniczna — PHP → Next.js, migracja bazy, growth hacking techniczny. Od rozbioru starej architektury PHP-owej, przez uzasadnienie wyboru Next.js i Supabase, migrację MySQL do PostgreSQL, po techniczne mechanizmy wzrostu: Core Web Vitals, crawl budget, conversion rate optimization i pragmatyczny monitoring.

Czego się nauczyłem

Co właściwie kupujesz za 800 złotych

Z perspektywy czternastu lat widzę wyraźnie, że za te 800 złotych nie kupiłem ani kodu PHP, ani bazy MySQL — kupiłem dystrybucję. Zaindeksowane URL-e, linki z forów, domenę, którą ludzie pamiętają. I okazuje się, że te trzy rzeczy mają zupełnie różną trwałość. Kod zestarzał się w ciągu kilku lat — PHP 5.x stał się obciążeniem, którego nikt nie chciał dotykać. Treść trzymała się znacznie dłużej, bo żarty z 2012 roku w 2025 nadal generowały ruch. Ale najdłużej przetrwała właśnie dystrybucja — pozycje w Google, autorytet domeny, backlinki — i to ona, niezależnie od stanu kodu pod spodem, zarabiała na siebie przez wszystkie te lata.

Gdybym dziś kupował kolejną stronę, w ogóle nie spoglądałbym na technologię, bo i tak bym ją przepisał. Patrzyłbym za to na liczbę zaindeksowanych stron, profil linkowania, ruch organiczny i rozpoznawalność domeny. Cała reszta jest w gruncie rzeczy wymienna.

Pułapka stabilnego przychodu

Przez czternaście lat AdSense wypłacał mniej więcej tyle samo — około 800 złotych rocznie. Z tego płynął na pozór logiczny wniosek, że strona jest stabilna, bo przelew co pół roku miał podobną wysokość. Dopiero z czasem zrozumiałem, jak bardzo była to iluzja. Ruch organiczny systematycznie spadał (brak HTTPS, zero mobile, zerowe structured data), ale jednocześnie CPM na polskim rynku powoli rósł, bo przybywało reklamodawców. Te dwie tendencje wzajemnie się kasowały — mniej odsłon pomnożone przez wyższą stawkę za odsłonę dawało w praktyce podobny przychód.

Metryka, którą obserwowałem, stała w miejscu; metryki, na które powinienem był patrzeć — pozycje, ruch, współczynnik odrzuceń — pogarszały się z roku na rok. Gdybym zamiast zaglądania raz na sześć miesięcy do AdSense regularnie analizował Google Search Console, zobaczyłbym spadki dużo wcześniej i być może zareagował w 2018, a nie w 2026. Przychód okazał się wskaźnikiem spóźnionym — zanim w końcu zaczyna spadać, degradacja pod spodem trwa już od lat.

Ryzyko jednego dostawcy

Patrząc wstecz, cały biznes suchary.com przez czternaście lat był uzależniony od jednej firmy. Google decydował o ruchu poprzez algorytm rankingowy, o przychodzie poprzez stawki AdSense i o widoczności poprzez politykę HTTPS, mobile-first indexing i Core Web Vitals. Każda zmiana po ich stronie — a przez te czternaście lat zmian było sporo — przekładała się bezpośrednio na moje przychody, a ja nie miałem żadnego bufora ani alternatywnego kanału.

Dlatego przy nowej wersji świadomie zbudowałem kilka niezależnych strumieni — zarówno po stronie ruchu (Google organic, ale również newsletter, push notifications i social sharing), jak i po stronie przychodu (AdSense plus własny system reklam oparty na Stripe'ie). Nie chodzi o to, żeby mieć wiele kanałów dla samej ich liczby — chodzi o to, żeby zmiana algorytmu albo korekta stawek CPM nie oznaczała, że z dnia na dzień tracę połowę dochodu bez żadnej możliwości reakcji.

Dlaczego dwie próby przepisania się nie udały, a trzecia tak

O Django i Wagtailu pisałem już wyżej, ale dopiero z perspektywy trzeciej próby widzę, co w istocie poszło nie tak. Obie technologie były dobre — to nie narzędzia zawiodły. Zawiodła proporcja. Zdecydowana większość pracy polegała na parsowaniu dumpa SQL, pisaniu kolejnych komponentów i konfiguracji deploya — czyli na rzeczach powtarzalnych i nudnych. Mniejszość to były ciekawe decyzje architektoniczne: jak zaprojektować schemat bazy, jak zbudować monetyzację, jak ułożyć SEO. Problem w tym, że solo developer, który siada do projektu po pełnym etacie, ma energię na te drugie, ale nie na te pierwsze. Po tygodniu bez widocznych efektów motywacja wyparowuje i repozytorium cichutko umiera.

AI od Claude Code odwróciło tę proporcję. Zamiast spędzać wieczory na parsowaniu SQL-a, opisywałem, czego potrzebuję, a implementację dostawałem wygenerowaną. Moja rola sprowadziła się głównie do podejmowania decyzji i code review — czyli do tej części pracy, na którą miałem energię. Dlatego trzecia próba zakończyła się działającym produktem, a nie kolejnym martwym repozytorium. Wąskim gardłem projektów pobocznych nie jest ani czas, ani umiejętności — jest stosunek pracy interesującej do pracy mechanicznej, i cokolwiek ten stosunek przesuwa na korzyść tej pierwszej, zwiększa szanse, że projekt dotrze na produkcję.

Budowanie z myślą o opcjach

Stary serwis miał w gruncie rzeczy jedną opcję — zbierać przelewy z AdSense. Nowy otwiera ich kilka: mogę dalej generować z niego cashflow, mogę go sprzedać za wielokrotność rocznego przychodu, mogę pokazywać go jako portfolio piece albo używać jako poligonu doświadczalnego do testowania technik SEO i monetyzacji na żywym organizmie. Ta zmiana — z jednej opcji na kilka — jest dla mnie warta więcej niż sama różnica w przychodzie, bo daje elastyczność, której wcześniej zwyczajnie nie miałem.

Z tego samego powodu nowa wersja ma Dockera, panel admina, compliance i udokumentowany deploy — nie dlatego, że ja potrzebuję tego jako jednosobowy operator (daję radę i bez tego), ale dlatego, że potencjalny kupujący powinien móc przejąć serwis w godzinę, bez grzebania w kodzie. Okazuje się, że budowanie z myślą o tym, ile ktoś byłby skłonny za to zapłacić — nawet jeśli nie planujesz sprzedaży — wymusza decyzje, które podnoszą jakość projektu, bo zmusza cię do dokumentowania, upraszczania i eliminowania zależności od jednej osoby.

Jeśli ten case study Cię zainteresował, zajrzyj do ścieżki biznesowej albo ścieżki technicznej.

Przypisy

XRumer — rosyjski program spamerski, szczególnie popularny w latach 2000–2010, który automatyzował rejestrację kont na forach i masową publikację linków spamerskich. Potrafił omijać CAPTCHA i w krótkim czasie rozsiewał tysiące komentarzy z odnośnikami.