Modny stack nie zawsze znaczy lepszy wybór. WordPress ma zalety, o których nikt nie mówi

Zmiana technologii na coś bardziej „AI-owego” brzmi dziś jak oczywisty krok rozwoju. AI ma budować strony w minutę z jednego opisu tekstowego, kreatory obiecują gotowy produkt bez programisty, a wśród programistów modne stały się własne zestawy technologii, na przykład Next.js. Problem w tym, że w większości projektów, które widzę, to decyzja podjęta na wyrost, zanim ktokolwiek policzył, czy nowy zestaw faktycznie rozwiązuje jakiś realny problem. WordPress ma swoje wady, ale ma też zalety, o których w tej dyskusji prawie nikt nie wspomina: niski koszt utrzymania, własną bazę danych i dojrzały, sprawdzony od lat system zarządzania treścią.

Fala AI przesunęła rynek w stronę kreatorów i własnych zestawów technologii

Narzędzia takie jak Framer z funkcjami AI, Lovable czy v0 obiecują gotową stronę z jednego promptu, bez linii kodu po stronie klienta. Wśród programistów zyskały popularność własne zestawy technologii: Next.js, Astro, architektury headless z Supabase albo Sanity jako źródłem treści. To realny i uzasadniony kierunek przy pewnych projektach, głównie tam, gdzie strona jest właściwie aplikacją z logiką biznesową, a nie prezentacją oferty. Problem zaczyna się wtedy, gdy ten kierunek staje się domyślnym wyborem dla każdego projektu, łącznie z prostą stroną firmową, która nie potrzebuje żadnej z tych rzeczy.

WordPress wygrywa tam, gdzie liczy się koszt utrzymania

Dedykowana aplikacja na Next.js z headless CMS-em ma więcej ruchomych części, niż na pierwszy rzut oka widać: hosting frontendu, hosting albo funkcje serverless dla logiki backendowej, zewnętrzna baza danych, subskrypcja headless CMS-a, czasem osobna usługa do logowania użytkowników. Każdy z tych elementów to osobna faktura miesięczna i osobny punkt, w którym coś może przestać działać, a odpowiedzialność za naprawę rozmywa się między kilku dostawców. WordPress ma większość tego wbudowaną w jeden pakiet, hostowaną od lat na dojrzałym, mocno konkurencyjnym rynku, gdzie solidny hosting kosztuje dziś kilkadziesiąt złotych miesięcznie, nie kilkaset.

Własna baza danych i CMS bez dokładania kolejnych usług do faktury

WordPress przychodzi z własną bazą danych, panelem administracyjnym dopracowywanym od dwudziestu lat i gotowym systemem zarządzania użytkownikami i rolami od pierwszej instalacji. Custom stack musi to zbudować od zera albo kupić jako osobną usługę: Supabase lub własny serwer bazy danych, Clerk czy podobne rozwiązanie do logowania, Sanity albo Contentful jako CMS. Dla aplikacji z prawdziwą logiką biznesową ten rozdział na wyspecjalizowane usługi ma sens. Dla strony firmowej, która ma prezentować ofertę i zbierać zapytania, to często przerost formy nad treścią: płacisz miesięcznie za elastyczność, z której nigdy nie skorzystasz.

Policzone na trzy lata, różnica robi się trudna do zignorowania

Solidny hosting pod dobrze zbudowaną stronę WordPress to dziś rząd od 50 do 150 złotych miesięcznie, w zależności od ruchu i wymagań. Własny zestaw technologii z osobnym hostingiem frontendu, funkcjami serverless, zewnętrzną bazą danych i subskrypcją headless CMS-a potrafi zejść nisko przy małym ruchu, ale rośnie szybko wraz ze skalą i zwykle mieści się w przedziale 300 do 600 złotych miesięcznie za porównywalny zestaw funkcji, licząc wszystkie usługi razem. W horyzoncie trzech lat to różnica rzędu kilkunastu tysięcy złotych, wyłącznie w kosztach utrzymania infrastruktury, zanim jeszcze doliczysz czas programisty potrzebny na spięcie tych wszystkich usług ze sobą i utrzymanie ich w zgodzie przy kolejnych aktualizacjach. To nie jest argument przeciwko nowym technologiom, to argument za tym, żeby dobierać je do skali projektu, nie do tego, co akurat modne.

Można zbudować WordPressa bez szablonów i page builderów, i to zmienia wszystko

Krytyka WordPressa, którą dziś najczęściej się słyszy, w większości dotyczy WordPressa postawionego na page builderze i garści kupionych wtyczek, nie samej platformy jako takiej. Pisałem już o tym, dlaczego taka konstrukcja z czasem zaczyna szwankować i odstrasza profesjonalnych programistów od dalszego rozwoju. Ręcznie kodowany motyw, dokładnie taki, na jakim stoi ten blog, omija większość tych problemów: nie ma zbędnego znacznika generowanego przez page builder, nie ma dziesiątek wtyczek odpowiedzialnych za pojedyncze sekcje strony, jest tyle kodu, ile faktycznie potrzeba, i ani grama więcej. To wciąż WordPress, więc dalej masz bazę danych, CMS i zarządzanie użytkownikami w standardzie, ale bez bagażu, przez który WordPress ma dziś złą sławę.

AI obniżyło koszt ręcznego kodowania WordPressa, nie jego wartość

To najbardziej nieoczywisty wątek w całej tej dyskusji. Narzędzia AI w praktyce ułatwiają dokładnie to, co wcześniej było najdroższą częścią pracy nad WordPressem: pisanie czystego, własnego kodu motywu od zera, zamiast sięgania po page builder jako skrót, żeby zmieścić się w budżecie klienta. To, co kiedyś wymagało wielu dni pracy programisty nad szablonem, dziś, z pomocą dobrych narzędzi AI, powstaje wyraźnie szybciej, bez utraty jakości kodu ani kontroli nad tym, co dokładnie się dzieje w motywie. Argument „WordPress trzeba budować na page builderze, bo inaczej to za drogie” traci więc sens szybciej, niż większość firm zdążyła to zauważyć.

Nie zawsze polecam WordPressa

W EpicBrand nie stawiamy WordPressa jako domyślnej odpowiedzi na każdy projekt. MVP z logiką biznesową i kontami użytkowników zwykle lepiej postawić na Next.js z bazą danych zaprojektowaną pod konkretny proces, nie pod publikowanie treści. Sklep z bardzo dużym ruchem albo nietypową logiką sprzedażową czasem lepiej obsłuży MedusaJS niż WooCommerce. Produkt cyfrowy, w którym logika aplikacji zmienia się co tydzień, potrzebuje elastyczności, jakiej żaden CMS nie da, bo CMS z założenia optymalizuje się pod treść, nie pod aplikację. WordPress wygrywa dokładnie tam, gdzie sednem projektu jest prezentacja oferty i regularna publikacja treści, nie logika aplikacji skrojona pod jeden, unikalny proces biznesowy.

Wybór technologii pod stronę czy produkt cyfrowy nie powinien być kwestią mody ani tego, o czym akurat głośno na konferencjach. Powinien wynikać z jednego pytania: co ta strona ma faktycznie robić przez najbliższe lata, i który stack pozwoli to robić najtaniej, najbezpieczniej i z najmniejszą liczbą rzeczy, które mogą się po drodze zepsuć. Dla sporej części firm odpowiedzią jest dobrze zakodowany WordPress – nie dlatego, że to bezpieczny wybór z przeszłości, tylko dlatego, że najlepiej pasuje do tego, co strona ma faktycznie robić.