WooCommerce czy dedykowany sklep internetowy na Laravelu: co wybrać i kiedy

O platformie nie decyduje lista funkcji na pierwszy dzień — magazyn, ceny B2B i wiele języków budujemy na obu. Decyduje to, kto rozstrzyga o Państwa kolejnej zmianie i ile ona kosztuje.

Pytanie o technologię, na które odpowiedzią nie jest lista funkcji

Rozmowa zaczyna się prawie zawsze tak samo: klient ma około siedmiuset produktów, trzy progi cenowe dla resellerów, z których każdy widzi w swoim profilu wyłącznie własną cenę, oraz księgowość w Visma Horizon, gdzie stan magazynowy jest prawdą, a sklep tylko go odzwierciedla. Pytanie, które pada, brzmi: WooCommerce czy dedykowany sklep internetowy? Odpowiedź, na którą czeka, to zestawienie w dwóch kolumnach: po jednej stronie coś jest, po drugiej tego nie ma — zestawienie, którego nie mamy i nie ma go nikt, kto obie platformy naprawdę buduje.

Moduł magazynowy z synchronizacją stanów w czasie rzeczywistym, progi cenowe B2B, system rabatów, obsługę wielu języków i migrację treści budujemy na obu platformach, a cena w naszym cenniku od platformy nie zależy: wersja Basic sklepu internetowego kosztuje 4500 €, a wersja Pro 9500 € — tak samo na WooCommerce, jak i na Laravelu. To właśnie te pięć pozycji dzieli Basic od Pro, a nie to, co jest pod spodem; panel administracyjny cennik wymienia już przy Basicu, a obsługi wielu walut nie ma w żadnej wersji i ustala się ją osobno, znowu na dowolnej platformie.

Wynika z tego rzecz praktyczna: platformę sprzedaje się Państwu listą funkcji na pierwszy dzień, czyli za coś, co da się mieć na oba sposoby, a porównanie zaczynające się od takiej listy jest skończone, zanim się zaczęło. Ciekawe pytanie zaczyna się krok dalej — kto decyduje o tym, co Państwa sklep będzie umiał w przyszłym roku, i jak długo ta decyzja czeka w kolejce u kogoś innego.

W pierwszym roku obie platformy robią to, za co Państwo zapłacili, bo w obu ktoś to właśnie zbudował; w drugim roku proces się zmienia — dochodzi sprzedaż hurtowa, drugi magazyn, obowiązek wystawiania faktur czytelnych maszynowo albo po prostu inny porządek rabatów — i od tego momentu obie drogi kosztują różnie. Na cudzym rozszerzeniu każda późniejsza zmiana jest jak przebudowa w wynajętym lokalu: reguły Państwa procesu żyją w cudzym oknie ustawień i przesuwają się w rytmie cudzych wydań. Na własnym kodzie to samo jest pracą, która ma w cenniku stawkę, a jedyne, co trzeba uzgodnić, to jej priorytet wobec reszty listy.

Co WooCommerce robi dobrze

WooCommerce sami wstawiamy do sklepów klientów za każdym razem, gdy proces do niego pasuje, i jest to najszerzej używany system e-commerce w badaniach W3Techs: 6 sierpnia 2026 roku działał na 8,2% wszystkich stron internetowych i stanowił 48,5% wszystkich systemów e-commerce w tych badaniach. Ważniejsze od samej liczby jest to, z czego ją policzono — z udziału wśród zbadanych systemów, nie wśród sklepów świata i z całą pewnością nie w obrocie e-commerce — a stoi za nią WordPress z 41,2% wszystkich stron internetowych.

Katalog wtyczek WordPress.org tego samego dnia pokazywał WooCommerce w wersji 11.0.0, zaktualizowanej 4 sierpnia, z szacunkiem „7+ million active installations”, a do ostrożnego czytania tej liczby zachęca sam producent: w rdzeniu pobranym z WordPress.org zliczanie użycia jest domyślnie wyłączone, więc nikt — również Automattic — nie wie, ile sklepów faktycznie handluje, i liczba ta jest górną granicą instalacji, a nie liczbą sprzedawców.

Strona cenowa producenta opisuje WooCommerce jako platformę open source bez opłaty platformowej i z 0% udziału w przychodach: nie płacą Państwo za to, że sprzedają, ani za to, że obrót rośnie. Katalog, lista zamówień i ustawienia rabatów wyglądają przy tym tak samo jak reszta administracji WordPressa, którą Państwa zespół najprawdopodobniej potrafi już obsługiwać bez szkolenia.

Najmocniejszy argument za WooCommerce w porównaniach z konkurencją znika prawie zawsze, a jest nim automatyczna łatka: 2 marca 2026 roku ujawniono podatność Store API, która dotyczyła wersji od 5.4 do 10.5.2 i pozwalała sfałszowanym żądaniem założyć konto administratora; błąd znalazł ktoś inny, nie właściciele sklepów; poprawkę przeniesiono na 52 objęte wersje; i tego samego dnia od godziny 14.00 czasu UTC zaczęła się ona automatycznie rozchodzić po sklepach z włączonymi automatycznymi aktualizacjami, bez faktury. Samo to ustawienie nie jest oczywiste i to właśnie je konfiguruje oraz pilnuje w umowie opieki konkretny człowiek; jak strony na WordPressie bywają przejmowane i co robić, gdy już do tego doszło, opisaliśmy w artykule o zhakowanej stronie WordPress.

Rekomendacja się przez to nie zmieniła i jest zapisana także na stronie naszej usługi: bardzo małemu sklepowi internetowemu ze standardowymi procesami — WooCommerce. Przy stu produktach z jedną ceną, jednym magazynem i jedną metodą płatności platforma dedykowana nie da niczego, za co warto byłoby dopłacić różnicę, a sprzedawanie droższego wariantu wtedy, gdy tańszy robi to samo, to jeden niezadowolony klient więcej i zero poleceń.

Czy WooCommerce nadaje się do łotewskich płatności i dostawy?

Nadaje się. Dostawa i płatności na Łotwie nie są miejscem, w którym gotowy sklep się zatrzymuje, a ostrzeżenia mówiące inaczej zwykle nie mają podstaw: Omniva publikuje gotowe moduły dla sześciu platform — WooCommerce, Shopify, PrestaShop, OpenCart, Magento i Mozello — a obok nich udokumentowany interfejs OMX, którym idą dane przesyłek, etykiety, zdarzenia śledzenia i listy paczkomatów we wszystkich trzech krajach bałtyckich, przy czym warunkiem jest umowa firmowa, a nie programista. DPD Baltics samo utrzymuje swoją wtyczkę do WooCommerce w katalogu WordPress.org — wersja 1.2.91, ponad 2000 aktywnych instalacji — i obejmuje paczkomaty, kuriera, etykiety, manifesty oraz płatność przy odbiorze; tam też widać jej publiczną ocenę 2,7 na 5 i opinie skarżące się na konflikty z innymi wtyczkami dostawy.

MakeCommerce, za którym stoi Maksekeskus AS, daje jedną umową linki płatnicze banków Swedbank, SEB, Citadele i Luminor, karty, Apple Pay i Google Pay, a obok tego dostawę Omniva, DPD, Venipak i Unisend; jego wtyczka do WooCommerce ma ponad 3000 aktywnych instalacji i ostatnią aktualizację z czerwca 2026 roku. Klix by Citadele, utrzymywany przez sam bank, publikuje oficjalne wtyczki dla sześciu platform, w tym dla WooCommerce od wersji 3.5, więc twierdzenie, że na Łotwie gotowy sklep nie potrafi przyjąć pieniędzy, byłoby po prostu nieprawdziwe.

Drugą stroną tego samego jest to, że ci dostawcy nie są własnością wtyczek: MakeCommerce, Omniva i DPD publikują interfejsy, nie tylko moduły, a w naszym cenniku podłączenie płatności — MakeCommerce i Stripe — mieści się już w wersji Basic za 4500 €, niezależnie od tego, która platforma jest pod spodem. Integracje z Horizonem, Jumisem, Pocztą Łotewską, Omnivą i DPD to pozycja usługi sklepowej, a nie dopłata za Laravel, a z interfejsami dostawy Omnivy, Poczty Łotewskiej, DPD i Venipaku pracujemy regularnie, więc łotewska warstwa dostaw i płatności nie jest argumentem ani za żadną z trzech dróg, ani przeciw niej.

Gdzie na Łotwie naprawdę jest praca

Zaplecze komplikuje to, że Visma Horizon, Jumis i Directo publikują każdy własny interfejs REST — dokumentacja Directo opisuje autoryzację nagłówkiem X-Directo-Key oraz dostęp do towarów, zamówień, klientów, faktur, stanów i formuł cenowych — ale opublikowany interfejs to jeszcze nie integracja: ktoś musi zestawić to, co sklep nazywa towarem, z tym, co księgowość nazywa pozycją asortymentową, i rozstrzygnąć, który z obu systemów przechowuje prawdę o stanie w tej sekundzie, w której kupujący naciska przycisk. Dwa miejsca ze stanem magazynowym są jak dwa zegary na statku: dopóki nikt ich nie zsynchronizuje, nikt nie zna godziny, a praca ta jest indywidualna na każdej platformie — z Horizonem i Jumisem robimy ją regularnie.

Nad tym stoi datowany fakt prawny z pułapką w środku: ustrukturyzowana faktura elektroniczna jest wobec instytucji publicznych obowiązkowa od 1 stycznia 2025 roku, a w obrocie między firmami stanie się obowiązkowa 1 stycznia 2028 roku — w trybie łotewskiej ustawy o rachunkowości i w formacie LVS EN 16931-1:2017. Pułapką jest data: pierwotnie przewidywano rok 2026, więc artykuły prasowe z 2024 roku wciąż podają nieprawidłowy termin, a sprawdzać go trzeba na stronie Ministerstwa Finansów o ustrukturyzowanej fakturze elektronicznej, nie w wiadomościach — bo w sklepie sprzedającym firmom drogę faktury czytelnej maszynowo ktoś na dowolnej platformie i tak zbuduje, niezależnie od tego, który rok okaże się właściwy.

WooCommerce czy dedykowany sklep internetowy: która z trzech dróg jest Państwa?

Porównania sprowadzające ten wybór do dwóch przycisków — WooCommerce czy Laravel — pomijają drogę, którą sprzedajemy najczęściej, bo dróg jest w rzeczywistości trzy; różnią się tym, jak duża część Państwa procesu żyje w kodzie, który mogą Państwo zmienić sami, a wybór między nimi jest wyborem tego, gdzie odtąd będą się znajdować Państwa reguły cen i zamówień — w oknie ustawień, we własnym repozytorium albo pośrodku.

Pierwsza droga to gotowe narzędzie z gotowymi rozszerzeniami — WooCommerce albo OpenCart, które istniejącym sklepom proponujemy również my. W rdzeniu WooCommerce są dwa pola ceny, zwykła i promocyjna, jedna liczba stanu na produkt lub wariant oraz trzy metody płatności, z których żadna nie przyjmuje pieniędzy online, więc cena dla konkretnej grupy klientów, rabaty ilościowe, zamiana oferty w zamówienie, zwolnienie z VAT i stany w kilku magazynach to osobny zakup od osobnego producenta z osobnym rocznym abonamentem. Droga ta jest najszybsza i bardzo często słuszna, a jej ceną nie są pieniądze, tylko to, że reguły Państwa procesu żyją odtąd w cudzym oknie ustawień.

Druga droga w porównaniach prawie się nie pojawia, choć sprzedajemy ją najczęściej: gotowe narzędzie z własnym kodem na wierzchu. WooCommerce to otwarty kod PHP, więc tabelę cen dla resellerów, kontrolę kredytu albo rezerwację stanu można napisać obok rdzenia, zamiast kupować jako wtyczkę, i licencji za to nie ma — są godziny — za tę cenę, że kod pozostaje przywiązany do rytmu aktualizacji WooCommerce i do tego, jak ta platforma przechowuje zamówienia. Znaczną część tego, co w naszym cenniku nazywa się wersją Pro za 9500 €, stanowi właśnie taka praca, i tutaj mieści się większość naszych własnych sklepów.

Trzecia droga to nasza własna platforma, w której katalog, koszyk, płatności i logika cen są napisane od pustego miejsca wokół Państwa procesu; to najdroższy początek i jedyny, w którym nie ma żadnego cudzego założenia co do tego, czym jest towar i kiedy zamówienie staje się zamówieniem. Wewnątrz trzeciej drogi jest rozgałęzienie: Bagisto i Lunar to pakiety commerce dla Laravela na licencji MIT — 6 sierpnia 2026 roku odpowiednio 27 943 i 3588 gwiazdek na GitHubie — które dają katalog i koszyk już napisane, w zamian za jeszcze jedną zewnętrzną zależność, której rytm nie jest w Państwa rękach. Tą drogą nie idziemy.

Ile kosztują roczne licencje wtyczek WooCommerce?

Dla sklepu z siedmiuset produktami i trzema progami dla resellerów pierwsza droga 6 sierpnia 2026 roku kosztowała 270 € rocznie za dwie publiczne ceny plus nieznaną trzecią. Dynamic Pricing za 113 € rocznie daje rabaty ilościowe i rabaty według roli; B2B for WooCommerce od Addify za 157 € rocznie daje ceny według roli, ceny progowe, zamianę oferty w zamówienie, zwolnienie z VAT oraz metody płatności i dostawy ograniczane według roli; ale dla stanów w kilku magazynach rdzeń nie przewiduje nic, więc dochodzi trzecia płatna wtyczka, na przykład Addify Multi Inventory Management, bez publicznej ceny rocznej.

Te 270 € rocznie to niewiele więcej niż pięć godzin programowania, bo godzina w naszym cenniku kosztuje 50 €, i za funkcje z producentem, dokumentacją i aktualizacjami jest to tanio. Cena, której nie znają Państwo przed rozmową, nie jest jednak pozycją w wycenie: wtyczka magazynowa tę liczbę podnosi, a o ile — zależy od oferty, która przyjdzie po podaniu liczby magazynów i wolumenu zamówień.

Inny sklep ma inne pozycje: ten, który sprzedaje subskrypcje, rezerwacje i poziomy członkostwa, płaci w tych samych cenach z Marketplace WooCommerce 245 € rocznie za WooCommerce Subscriptions, 218 € za Bookings, 175 € za Memberships, 140 € za AutomateWoo i 70 € za Product Add-Ons — razem 848 € rocznie. Przez pięć lat, jeśli ceny nie wzrosną, daje to 4240 €: prawie całą cenę sklepu w wersji Basic, która w naszym cenniku wynosi 4500 €, i prawie połowę wersji Pro za 9500 €. Pozycja ta się nie amortyzuje, bo dotyczy jednej strony, jednego roku i płacona jest co roku od nowa.

Ta sama liczba odwrócona to prawie 85 godzin programowania po 50 € — godzin, które zostają w Państwa kodzie i Państwa własności, zamiast odnawiać się na fakturze w przyszłym roku. Rachunek na 848 € jest przy tym rachunkiem sklepu z subskrypcjami, rezerwacjami i członkostwami, a nie normą — normy tu nie ma i każdy sklep liczy tę pozycję z własnego procesu. Licencje dochodzą też do budowy, a nie zamiast niej: w obu przypadkach ktoś sklep najpierw zbudował, i tylko w jednym za zbudowane przychodzi w kolejnym styczniu następna faktura.

Co robi faktura, której nikt nie opłaci

Jeśli abonamentu się nie odnowi, dokumentacja WooCommerce.com mówi to wprost: „the extension or theme remains installed on your site but will no longer receive updates” — wtyczka zostaje zainstalowana, sklep dalej działa, a znikają wyłącznie aktualizacje. Skutkiem nieodnowionej licencji nie jest więc przestój, który zauważa się tego samego dnia, tylko niepoprawiany kawałek kodu, który wciąż obsługuje płatności; jeden abonament obejmuje przy tym jedną stronę produkcyjną i jedną deweloperską, a subdomeny liczą się osobno.

Jedna pozycja zachowuje się inaczej, i tak samo po obu stronach: konektor księgowy zwykle nie jest licencją, tylko abonamentem rosnącym z liczbą zamówień — MyWorks Xero Sync zaczyna się w Marketplace WooCommerce od poziomu bezpłatnego, dalej cenę wyznacza wolumen, więc pozycja ta rośnie dokładnie wtedy, gdy rośnie sklep. Platforma dedykowana tego nie usuwa, zmienia tylko to, kto konektor utrzymuje, a u nas są to godziny; pozycji nie należy też mnożyć na wyrost: obsługa wielu języków to nie automatycznie 99 € rocznie za WPML Multilingual CMS, bo obok WPML stoi Polylang, natomiast tańsza licencja WPML Multilingual Blog za 39 € e-commerce nie obsługuje, więc dla sklepu wybór między 39 € a 99 € nie istnieje.

Dlaczego różnica pojawia się w drugim roku

Sama platforma pokazuje, że cena zmiany jest wydatkiem realnym, a nie teoretycznym: od 2023 roku WooCommerce usunął dwie nośne części, wycofał jedną funkcję w wersji beta i zmienił jedno ustawienie domyślne. Legacy REST API zniknęło z rdzenia 11 czerwca 2024 roku wraz z wersją 9.0, uznane za przestarzałe już od wersji 2.6 w 2016 roku; wbudowana bramka PayPal Standard została usunięta w wersji 8.9 w maju 2024 roku; wersję beta edytora produktów wycofano w wersji 11.0, która pojawiła się w katalogu 4 sierpnia; natomiast przechowywanie zamówień HPOS stało się domyślne dla nowych instalacji w wersji 8.2 w październiku 2023 roku i istniejących sklepów nie dotyczy, dopóki ktoś ich nie zmigruje.

Na tym tle w kategorii Advisories na blogu deweloperskim WooCommerce w dwunastu miesiącach do 5 sierpnia 2026 roku jest 37 wpisów — około trzech miesięcznie — i każdy trzeba sprawdzić wobec każdego zainstalowanego rozszerzenia, co sklep z czterema wtyczkami przyjmuje bez wysiłku, a sklep z dwudziestoma już nie. Sterta nie narasta przy tym w jeden dzień: wtyczki dochodzą po jednej, każda z osobna jest decyzją całkowicie rozsądną, a mnożenie się kombinacji do sprawdzenia odbywa się po cichu.

Dziesięć wtyczek to nie dziesięć części, tylko dziesięć umów, z których każda może się skończyć osobno, a właściciel zmienia się również wtedy, gdy kodowi nic nie dolega. 31 października 2025 roku serwis opinii Judge.me wyłączył swoją integrację z WooCommerce razem ze Square, Squarespace, BigCommerce, Dudą i PrestaShop: do danych można było sięgać do 19 listopada, potem dostęp usunięto bezpowrotnie, a wideo z opiniami nie weszło do eksportu, więc zbierany latami zasób marketingowy częściowo został po drugiej stronie drzwi. Spokojniejsze przypadki są bardziej przekonujące: w 2019 roku Automattic kupił Prospress, autora WooCommerce Subscriptions i AutomateWoo, w 2020 roku GoDaddy kupił SkyVerge, z którego ponad sześćdziesięciu wtyczek korzystało ponad 100 000 sprzedawców, i oba przejęcia — na ile można sądzić z publicznie wiadomego — skończyły się dla sprzedawców dobrze. Rzecz nie w szkodzie, tylko w tym, że właściciel składowej Państwa sklepu może się zmienić bez Państwa udziału.

Jak duże jest to ryzyko naprawdę

Skala je relatywizuje, a liczby są tu nasze własne: w zestawieniu z 6 sierpnia 2026 roku API wtyczek WordPress.org zwróciło 7764 wtyczki z tagiem „woocommerce”, z czego 23,1% nie było aktualizowanych od dwóch lat lub dłużej, ale w tym samym zestawieniu 10 809 800 aktywnych instalacji przypada na wtyczki zaktualizowane przez ostatnie sześć miesięcy, a tylko 208 790 na takie, których nie ruszano ponad trzy lata. Wtyczek z 10 000 i więcej instalacji, które od dwóch lat pozostają bez aktualizacji, jest w tym samym zestawieniu dokładnie sześć.

Porzucona wtyczka prawie nigdy nie jest tą popularną, którą znają wszyscy: ryzyko tkwi w jednym wąskim module, którego wymaga dokładnie Państwa proces — w progach cenowych B2B, w konektorze magazynowym, w generatorze etykiet konkretnego kuriera — i im bardziej Państwa proces odbiega od przeciętnego, tym bliżej są Państwo tej części katalogu, w której ostatnia aktualizacja pochodzi sprzed dwóch lat. Pozycję tę można zmniejszyć bez przebudowy: w umowie opieki robimy to my — zmniejszamy liczbę wtyczek, konfigurujemy aktualizacje, utrzymujemy monitoring — a przebudowa jest odpowiedzią dopiero wtedy, gdy problemem przestaje być opieka, a staje się to, że proces nie jest nigdzie zapisany.

Gdzie kształt danych WooCommerce zaczyna uwierać

Drugim miejscem, w którym drugi rok kosztuje, jest kształt danych, a najpierw ta jego strona, po której argument ten przestał być prawdziwy: zamówienia w nowych instalacjach od wersji 8.2 leżą w czterech własnych tabelach, a marcowy pomiar samej firmy z 2023 roku pokazuje, że nowe przechowywanie operacje na zamówieniach przyspiesza, a nie hamuje. Uwiera strona produktowa i najlepiej napisali o tym sami deweloperzy WooCommerce, 1 kwietnia 2019 roku objaśniając poprawki wydajności w wersji 3.6: towary i warianty idą przez system wpisów WordPressa, gdzie post meta jest nadzwyczaj elastyczne, ale „not that efficient when we need to sort or filter by many meta values at once” — niezbyt wydajne, gdy trzeba jednocześnie sortować lub filtrować po wielu wartościach meta. Odpowiedzią w tym samym wydaniu było wc_product_meta_lookup, zdenormalizowana tabela pomocnicza z SKU, ceną i statusem stanu obok post meta, a nie zamiast niego, więc kształt podstawowy pozostał, jaki był.

Równoważna praca po stronie produktów, woocommerce-product-tables-feature-plugin, od 16 października 2017 roku żyje wyłącznie na GitHubie i porzucona nie jest — ostatnie zmiany są z 31 lipca 2026 roku — tyle że za dostatecznie stabilną dla katalogu WordPress.org wciąż jej się nie uznaje. Obok stoi wp_options: pole autoload domyślnie nie ma indeksu, dane wczytywane automatycznie są odczytywane przy każdym wywołaniu strony, sama WooCommerce zaleca trzymać tę tabelę poniżej mniej więcej 500 wierszy, a jej przyrost powodują właśnie rozszerzenia, wtyczki i motywy — ta sama sterta, o której była mowa wcześniej, tylko oglądana od strony bazy danych.

Co Laravel daje sklepowi, czego gotowe narzędzie nie daje

Laravel nie jest sklepem i nie udaje, że jest: daje nazwane, udokumentowane i objęte licencją MIT części, z których sklep ktoś składa, więc pytaniem wartym tu pieniędzy nie jest „czy framework jest dobry”, tylko „które części Państwa procesu staną się wreszcie Państwa własnymi tabelami i Państwa własnymi zadaniami”. W sklepie handlowca odpowiedzią są zwykle cztery pozycje — tabela cen dla resellerów, limit kredytowy, rezerwacja stanu i synchronizacja z księgowością — i to właśnie je w gotowym narzędziu kupują Państwo od czterech różnych producentów, a potem uzgadniają między sobą.

Wcześniej trzeba jednak uczciwie powiedzieć, czego ta droga nie daje, bo żadnej z tych czterech pozycji nie daje też sam Laravel: oficjalne zestawy startowe frameworka dają uwierzytelnianie i nic więcej — nie ma ani katalogu, ani koszyka, ani kroku płatności, ani magazynu — a jedynym pakietem commerce w komplecie jest Cashier, który obsługuje faktury subskrypcyjne po stronie Stripe'a lub Paddle'a i zakłada, że produkty z cenami są już opisane w panelu operatora płatności. Tym, co Laravel daje, jest kształt, w którym te cztery pozycje są tanie do napisania i jeszcze tańsze do późniejszej zmiany.

Kolejki, transakcje i własny kształt bazy danych

Pierwszą częścią są kolejki: jedno API nad kilkoma silnikami — Redis, baza danych, Amazon SQS, Beanstalkd — dzięki któremu obsługa zamówienia, synchronizacja z ERP i wysyłka e-maila wychodzą poza żądanie, więc kupujący nie czeka już, aż odpowie system księgowy. Dokumentacja nazywa też to, co rozstrzyga o realnym wdrożeniu: łańcuchy i partie zadań, zadania unikatowe, których kolejka nie wykona dwa razy, ponowne próby oraz magazyn zadań nieudanych, z którego można je uruchomić jeszcze raz. Dwukrotnie wykonane zamówienie to faktura, którą ktoś potem musi anulować, i klient, który zauważy to szybciej niż Państwo.

Horizon pokazuje przepustowość kolejek, czasy wykonania i błędy, pozwala opisać konfigurację workerów w kodzie i ostrzega, gdy kolejka czeka zbyt długo, ale wymaga Redisa i z Redis Cluster obecnie nie współpracuje — jest więc osobną pozycją na rachunku za hosting, nie darmowym dodatkiem. Transakcje z kolei są tym, co w praktyce znaczy zdanie „zamówienie i ruch magazynowy dzieją się oba albo żadne”: DB::transaction w razie błędu sam wycofuje zmiany i pozwala je powtórzyć, jeśli baza danych trafi w zakleszczenie.

Dokumentacja Laravela nazywa migracje kontrolą wersji dla bazy danych, a w praktyce znaczy to, że tabele, indeksy i klucze obce projektują Państwo wokół własnej logiki cen i stanów, a nie wokół tego, co ktoś inny kiedyś rozstrzygnął o pojęciu towaru. Wyszukiwanie i faktury subskrypcyjne pozostają wyborem, nie obowiązkową pozycją miesięczną: Scout indeksuje na miejscu, w bazie danych, indeksami pełnotekstowymi MySQL-a lub PostgreSQL-a i bez zewnętrznej usługi, a stronę Stripe'a obsługuje Cashier, o ile subskrypcje w sklepie w ogóle są.

Tabela cen, limit kredytowy i rezerwacja w kodzie

Jak wygląda to konkretnie, najlepiej pokazuje pierwsza z czterech pozycji: tabela cen dla resellerów na własnym kodzie to jedna migracja z czterema kolumnami — grupa klientów, towar, próg ilościowy i cena — oraz indeks unikatowy na pierwszych trzech, dzięki czemu cenę dla konkretnego kupującego znajduje jedno zapytanie z jednym złączeniem, a nie przeszukiwanie wartości meta, i nowy próg cenowy jest nowym wierszem w tabeli, a nie nowym ustawieniem w cudzym oknie. Kiedy po roku dochodzi czwarty próg z innym sposobem zaokrąglania, zmienia się jedno miejsce i jeden test, a oba są w Państwa repozytorium.

Limit kredytowy i rezerwacja stanu to ta sama myśl o krok dalej, bo i tam wszystko trzyma się na jednej tabeli i jednej transakcji: suma nieopłaconych faktur jest kolumną przy kliencie, a sprawdzenie odbywa się w tej samej transakcji, w której powstaje zamówienie, więc dwa jednocześnie złożone zamówienia nie prześlizgną się oba pod limitem, a w razie zakleszczenia transakcja powtarza się sama. Rezerwacja z kolei jest wierszem z terminem ważności, który powstaje razem z zamówieniem i znika wraz z zaplanowanym zadaniem w tle, jeśli zamówienie nie zostanie opłacone, więc stan magazynowy przestaje być liczbą, którą dwóch kupujących może opróżnić jednocześnie.

Synchronizacja z księgowością jest zadaniem kolejkowym oznaczonym jako unikatowe, więc ponowna próba nigdy nie wystawi faktury dwa razy, a kiedy Horizon pokazuje rano, że w nocy po stronie księgowości była przerwa, magazyn zadań nieudanych pozwala uruchomić je jeszcze raz po kolei, zamiast przepisywać ręcznie. Każda z tych czterech pozycji jest dostępna także w gotowym narzędziu, tyle że jako okno ustawień producenta, którego reguł Państwo nie widzą, które po każdej aktualizacji trzeba sprawdzać od nowa i które na inną platformę się nie przenosi.

Dwie realizacje, które już działają

Jak wygląda to w projekcie, a nie w dokumentacji, widać po naszych własnych wdrożeniach na Laravelu. Na platformie zamawiania jedzenia LIDO o cenie decyduje nie towar, lecz adres: geolokalizacja wyznacza strefę dostawy, odległość i opłatę, każda z trzynastu restauracji ma własny asortyment dań, a obok sklepu działa osobny system automatyzacji procesów, do którego trafiają wszystkie zamówienia i z którego idą do restauracji i kucharzy — z integracjami z ponad dziesięcioma innymi systemami, w tym z Wolt, QWQER i RKeeper. W sklepie Riga Lashes na Laravelu są ceny wariantów, konta klientów, lista życzeń i cennik usług studia, a za nimi magazyn towarów, integracje z kurierami i płatności, gdzie proces jest zautomatyzowany aż po etap pakowania. W obu przypadkach rozstrzygającą część trzeba by napisać również na gotowym narzędziu, tyle że wewnątrz cudzej formy ceny i zamówienia, i to jest różnica, która zostaje: na własnym kodzie ta praca to jedno repozytorium bez osobnego abonamentu za każdą zdolność, a po każdej aktualizacji platformy nie trzeba jej sprawdzać od nowa. W Laravelu piszemy od 2013 roku i działa na nim większość naszych systemów dedykowanych, portali sektora publicznego i platform B2B.

Dokąd idą pieniądze, których nie ma w licencjach, jest pytaniem konkretnym i odpowiedź jest równie konkretna: prawie 85 godzin, które przez pięć lat kosztuje pozycja licencji za 848 € rocznie, na własnym kodzie to dokładnie ta tabela cen, ten limit kredytowy, ta rezerwacja i ta synchronizacja, napisane wokół Państwa procesu. Zostają one w Państwa repozytorium także wtedy, gdy kiedyś przestaniemy być Państwa partnerem: w budowie na zamówienie kod jest Państwa od pierwszego dnia, i jest to zapisane również na stronie naszej usługi Laravel.

Filament: panel administracyjny, którego nikt nie pisze od zera

Panelową część zarzutu, że we własnym systemie wszystko trzeba pisać od zera, zdejmuje Filament — framework interfejsu open source dla aplikacji Laravela. Zasoby generują ekrany CRUD dla modeli Eloquenta, kreator tabel daje filtrowanie, sortowanie i stronicowanie, komponenty formularzy przychodzą z wbudowaną walidacją, a uprawnienia dostępu Filament odczytuje wprost z polityk modeli Laravela, więc sprawdzania ról nie trzeba pisać drugi raz. Menedżery relacji, widżety pulpitu i powiadomienia są w tym samym komplecie; obsługa wielu podmiotów (multi-tenancy) również, choć z własnym ostrzeżeniem Filamenta, że to zestaw narzędzi, a nie gwarancja, i że za rozdzielenie danych między podmiotami odpowiada wdrażający; cała warstwa jest na licencji MIT, tak samo jak sam Laravel, więc opłat licencyjnych nie ma tam żadnych.

Najważniejsze jest jednak nie to, co framework rysuje, lecz to, dokąd idą uwolnione pieniądze: ekrany edycji towarów, tabele zamówień, filtry i sprawdzanie uprawnień to ta część prac, której kupujący nigdy nie widzi, a za którą zamawiający i tak płaci pełną stawkę, i kiedy daje je framework, budżet idzie na logikę cen, zamówień i magazynu, dla której w ogóle wybrano wykonanie dedykowane. Przykład jest tam, gdzie to Państwo czytają: ta strona działa na Laravelu 13 i Filamencie 5, a cała praca redakcyjna w dwunastu językach odbywa się w panelu, który skonfigurowaliśmy, a nie napisaliśmy od zera.

Gdzie kończy się framework, a zaczyna sklep

Filament nie jest sklepem i granicę tę warto narysować wyraźnie: framework daje panel administracyjny — ekrany, tabele, formularze i sprawdzanie uprawnień — ale nie wie nic o tym, co się w tych tabelach znajduje i według jakich reguł tam trafia. Katalog towarów z wariantami i atrybutami, koszyk, krok płatności, reguły cen z poziomami klientów i rabatami ilościowymi, cykl życia zamówienia od utworzenia po zwrot oraz rezerwowanie stanów w magazynie — niczego z tego w komplecie Laravela i Filamenta nie ma. Filament jest jak wykończony warsztat z regałami, stołami i światłem; co w nim produkować, w komplecie nie przychodzi.

Sama dokumentacja pokazuje, jak dosłownie trzeba to rozumieć: modele Order i Payment pojawiają się w niej wyłącznie jako przykłady pisane przez programistę, bo takich klas we frameworku nie ma. Nie jest to wada frameworka, tylko podział pracy: Filament obiecuje interfejs administracyjny i nic poza tym, tak samo jak Laravel obiecuje framework, a nie gotową aplikację. Skraca więc pracę administracyjną, ale nie skraca niczego w tej części, dla której w ogóle wybrano wykonanie dedykowane.

Dlatego w naszym cenniku wersja Basic sklepu za 4500 € przychodzi bez modułu magazynowego, obsługi wielu języków, progów cenowych B2B, systemu rabatów i migracji treści, a wersja Pro za 9500 € — z nimi wszystkimi. Różnica nie jest narzutem za nowocześniejszą technologię, tylko ceną tego, co ktoś musi napisać, i właśnie dlatego jest jednakowa na obu platformach. System na Laravelu o stałym zakresie od 8000 € jest w cenniku już inną pozycją i innym produktem: to nie sklep, tylko system, w którym od pustego miejsca powstaje cały proces.

Czego nie obiecujemy: gdzie wykonanie dedykowane kosztuje więcej

Sklep zbudowany na zamówienie jest wolny od rocznych licencji wtyczek, a nie od opieki, i są to dwie zupełnie różne rzeczy. Laravel daje każdemu wydaniu 18 miesięcy poprawek błędów i dwa lata poprawek bezpieczeństwa, nową wersję główną wypuszcza raz w roku, a poziomu wsparcia długoterminowego tam nie ma, więc daty są konkretne: Laravel 13 ukazał się 17 marca 2026 roku z poprawkami bezpieczeństwa do 17 marca 2028 roku, okno bezpieczeństwa Laravela 11 zamknęło się 12 marca 2026 roku, a poprawki błędów Laravela 12 kończą się 13 sierpnia 2026 roku. Raz na rok albo dwa system trzeba więc przenieść na nową wersję główną, a dokumentacja Laravela mówi, że twórcy starają się umożliwić to w dzień lub szybciej — staranie, nie obietnica co do tego, ile potrwa to w Państwa systemie.

Bieżnia wersji PHP jest przy tym ta sama po obu stronach: każda wersja ma dwa lata aktywnego wsparcia i dwa lata samych poprawek bezpieczeństwa, więc w pięcioletnim oknie mieści się co najmniej jedno, a zależnie od momentu cyklu, w którym Państwo zaczynają, do dwóch wymuszonych przejść na nowe PHP — niezależnie od tego, co jest pod spodem. Ani sklep na WooCommerce, ani na Laravelu tej pozycji nie ominie, a planuje ją w obu przypadkach ten sam człowiek, który planuje resztę opieki — różnica jest tylko taka, że na własnym kodzie przejście robi się wtedy, kiedy Państwu wygodnie, a nie wtedy, gdy któreś rozszerzenie przestaje wspierać starą wersję.

Trzy pozycje, w których wygrywa gotowe narzędzie

Droższe od opieki są trzy inne pozycje, a pierwszą z nich jest ekosystem: tutaj gotowe narzędzie wygrywa bez dyskusji. Kolejna automatyzacja marketingowa w sklepie na WooCommerce to wpis w Marketplace — na przykład AutomateWoo kosztuje 140 € rocznie — i w naszym doświadczeniu dzień pracy, podczas gdy w systemie zbudowanym na zamówienie jest to specyfikacja, godziny i test, a przy 50 € za godzinę to pierwsza funkcja, przy której zapytają Państwo, czy naprawdę jest potrzebna; pola towaru ani nowego filtru w administracji na tej liście nie ma, bo daje je framework. Brak ekosystemu nie jest kosztem jednorazowym, tylko trwale wyższym progiem dla wszystkiego, co później chce się wypróbować, a sklepowi, który dużo eksperymentuje, może to przeważyć nad rachunkiem za licencje — dlatego tego rachunku nie nazywamy argumentem głównym.

Druga to zależność od jednego zespołu, a odpowiada na nią struktura, nie deklaracja: kod w budowie na zamówienie jest Państwa od pierwszego dnia, piszemy go w standardowej strukturze Laravela bez egzotyki, krytyczna logika ma testy, a razem z nim przychodzi udokumentowany README i CI, żeby system mógł przejąć ktoś inny. Programistów Laravela na Łotwie łatwo znaleźć i dlatego nasza własna odpowiedź na pytanie, dlaczego Laravel, kończy się zdaniem, że nie pozostają Państwo zależni od jednego zespołu, także od nas — ryzyka to nie znosi, ale czyni je przenośnym.

Trzecia to PCI DSS i jest przeciwko nam. Opublikowana w styczniu 2025 roku redakcja SAQ A, która weszła w życie 31 marca 2025 roku, zwolniła z wymagań 6.4.3 i 11.6.1 — inwentaryzacji skryptów, ich uzasadnienia i nadzoru nad zmianami — oraz z wymagania 12.3.1 dotyczącego ukierunkowanej analizy ryzyka tych sprzedawców, których stronę płatności w całości i bezpośrednio dostarcza zgodny z PCI DSS usługodawca i którzy sami potwierdzili, że ich strona internetowa nie jest narażona na ataki oparte na skryptach, wskazując jednocześnie, że samych wymagań PCI DSS to nie uchyla. Ułatwienie to opisuje mały sklep na WooCommerce ze stroną płatności banku znacznie precyzyjniej niż krok płatności, który rysujemy we własnym kodzie, a obok stoi drugi równie niewygodny fakt: marcową podatność znalazł i naprawił ktoś inny, natomiast w systemie, który napisaliśmy my, robi to nasz zespół, więc opieka jest tam pozycją umowy, a nie założeniem.

Nasze zależności nie są innego gatunku

Filament jest dokładnie taką samą zależnością od trzeciej strony jak wtyczki, o których przed chwilą była mowa, a różnica między nimi jest różnicą stopnia i położenia, nie zasady. Jest to jedna zależność na licencji MIT w warstwie deweloperskiej, jej kod znajduje się w naszym repozytorium i daje się odgałęzić, a na ścieżce płatności kupującego nie stoi, bo rysuje panel administracyjny, a nie przyjmuje płatność.

Gdyby projekt jutro się zatrzymał, sklep dalej przyjmowałby zamówienia, a starzałaby się ta część, którą widzą Państwa pracownicy, nie ta, która bierze pieniądze od kupującego. Filament publikuje też tabelę wsparcia wersji z konkretnymi datami: wersja trzecia ukazała się w sierpniu 2023 roku i poprawki bezpieczeństwa dostaje do 1 stycznia 2028 roku, co jest oknem dłuższym, niż sam Laravel daje własnym wydaniom.

Filament nie jest jednak pakietem first-party Laravela, bo Laravel nie wymienia go na liście swoich pakietów, a za projektem nie stoi firma z bilansem, tylko zespół wokół jednego opiekuna: pod jego nazwiskiem jest w repozytorium około 17 000 zmian, przy około 2400 u kolejnego współautora, a finansowanie pochodzi od sponsorów z GitHuba i z płatnych konsultacji. Rytm wydań też nie jest łagodny: wersja czwarta ukazała się w sierpniu 2025 roku, piąta już w styczniu 2026 roku, dwa dni po Livewire 4, czyli kolejnej zależności od trzeciej strony pod spodem. A zdanie „w razie potrzeby to odgałęzimy” jest tanie do napisania i drogie do wykonania.

Nie oferujemy sklepu bez zależności od trzecich stron, bo takiego nie ma ani u nas, ani u nikogo innego; oferujemy mniejszą ich liczbę, licencję pozwalającą kod zatrzymać i utrzymywać samodzielnie oraz wyraźną granicę między tym, co w razie awarii zatrzymuje przepływ pieniędzy, a tym, co psuje pracownikowi dzień pracy. Jeśli różnica ta nie wydaje się Państwu dostatecznie duża, jest to zastrzeżenie całkowicie uzasadnione — i wtedy zbudujemy Państwu gotowe narzędzie, bo jest to ta sama wersja Basic albo Pro za tę samą cenę. Żadna z obu odpowiedzi nie czyni z nas niewłaściwego partnera.

Jak dokonujemy tego wyboru w praktyce

Razem z platformą kupują Państwo odpowiedź na jedno pytanie — kto może zmieniać Państwa reguły cen i zamówień i w jakim terminie — a na własnym kodzie odpowiedź brzmi „Państwo, w następnym sprincie”, natomiast na rozszerzeniu cudzego producenta „kiedy producent włączy to do swojego wydania, o ile włączy”. Dlatego w rozmowie rozpoznawczej nie pytamy o obrót, tylko o to, ile progów cenowych mają Państwo naprawdę i czy jeden klient widzi kiedykolwiek inną cenę niż drugi — to jest granica między dwoma polami ceny, które WooCommerce daje sam, a tabelą cen, którą ktoś musi utrzymywać.

Potem pytamy, czy stan magazynowy żyje w więcej niż jednym miejscu, bo magazyn plus półka sklepowa to już dwa miejsca, a dwa miejsca znaczą, że ktoś musi rozstrzygnąć, które z nich liczy się jako prawda. Kolejne dwa pytania rozstrzygają zwykle wszystko: czy zamówienie staje się zamówieniem od razu, czy też potrzebuje najpierw zatwierdzenia — działu zakupów klienta, Państwa kierownika sprzedaży albo limitu kredytowego — oraz czy proces sprawdziłby się również wtedy, gdyby katalog urósł dwukrotnie.

Jeśli odpowiedź o zatwierdzenie brzmi „tak”, są Państwo w miejscu, w którym rynek gotowych wtyczek jest najsłabszy: nadzoru nad limitami kredytowymi i blokowania zamówień ponad limit nie ma ani w rdzeniu, ani w popularniejszych pakietach B2B, a obiecuje je tylko kilka wyspecjalizowanych wpisów, na przykład QuarkCode B2B Commerce Suite. Ile z procesu są Państwo gotowi przerobić pod narzędzie — to pytanie, które zostaje, a niejasne wymagania są najdroższym błędem w całym zamówieniu, o czym pisaliśmy osobno.

Jeśli odpowiedzi mieszczą się w gotowym narzędziu, proszę wziąć gotowe narzędzie, bo będzie taniej — zbudujemy je Państwu my. Jeśli nie mieszczą się jedna albo dwie, są Państwo najprawdopodobniej na drodze środkowej, której w cenniku odpowiada ta sama wersja Pro za 9500 € na WooCommerce — ta sama cena co na Laravelu, bo płaci się za pracę, nie za platformę. Jeśli nie mieszczą się trzy albo więcej, a zwłaszcza jeśli jest wśród nich krok zatwierdzenia albo limit kredytowy, rozmowa przestaje być o platformie, a zaczyna być o tym, jak duża część procesu żyje w kodzie, który możemy zmienić bez uzgodnień z cudzym producentem.

Trzy początki i co kosztuje każdy z nich

W praktyce sprzedajemy trzy początki i każdy z nich ma cenę, którą da się policzyć: pierwszy to zacząć od katalogu, płatności i dostawy, uruchomić, a ceny B2B, logikę rabatów i integracje magazynowe dołożyć wtedy, gdy widać pierwsze realne zamówienia — w naszych odpowiedziach nazywamy to zwykle wyborem właściwym. Drugi to przeniesienie istniejącego sklepu, a jest to projekt, nie przełącznik: strukturę adresów zachowujemy, ale modele danych nie pokrywają się jeden do jednego, i każdą wtyczkę, która trzymała własne pola, trzeba ocenić osobno. W wersji Pro i w wynajmie migracja jest wliczona; w wersji Basic jej nie ma i wyceniamy ją osobno według zakresu, bo o cenie decyduje ilość danych i liczba pól.

Trzeci to wynajem: sklep na Laravelu razem z naszym hostingiem od 130 € miesięcznie plus 600 € jednorazowej opłaty konfiguracyjnej, a jego skład w cenniku jest ten sam co w wersji Pro — moduł magazynowy, obsługa wielu języków, progi cenowe B2B, system rabatów i migracja treści — tylko z hostingiem, aktualizacjami i opieką w komplecie; dostępny jest wyłącznie na Laravelu, bo sklepu na WooCommerce wynająć u nas nie można. Sam wybór platformy rozstrzyga kilka rzeczy, których praca nie wyrównuje: tę pozycję wynajmu, bezpłatne automatyczne łatki rdzenia, próg ekosystemu oraz to, kto musi się zgodzić, zanim Państwa kolejna zmiana trafi na produkcję. Cała reszta jest pracą.

Wynajem zaczyna się od 130 € miesięcznie, co przez pięć lat daje od 7800 €, plus 600 € konfiguracji — od 8400 € — i mieści w sobie hosting, aktualizacje oraz opiekę. Wersja Pro kosztuje 9500 € jednorazowo, a hosting przychodzi do niej osobno: nasz wynajem infrastruktury zaczyna się od 45 € miesięcznie, czyli od 2700 € przez pięć lat, razem od 12 200 €, a aktualizacji aplikacji jeszcze w tym nie ma. Obie liczby to dolne granice, nie sumy, a porównywalne są dlatego, że w cenniku skład obu jest ten sam. W wynajmie płacą Państwo za używanie razem z hostingiem, w budowie za system od razu, a w zestawieniu obu dolnych granic wynajem w oknie pięcioletnim zaczyna się niżej. Gdzie każda się kończy, rozstrzyga skala, dlatego obie wyceniamy do projektu, a nie odczytujemy z cennika.

Dalej praca idzie w dwutygodniowych sprintach z demo po każdym; płatności, firmy kurierskie i księgowość podłączamy i sprawdzamy przed uruchomieniem; produkty, klientów i historię zamówień przenosimy, zachowując strukturę adresów. Przy większych, niestandardowych pracach rozliczamy się w modelu czasu i materiałów z tygodniowym limitem, bo cena stała znaczy tam zwykle albo narzut za ryzyko, albo spór o zakres, a stawka godzinowa w cenniku wynosi 50 €. Cała droga zajmuje 8–32 tygodnie. Proszę zamówić wycenę projektu i rekomendację technologii — odpowiedzą Państwo na te same pytania nam, a my powiemy, która z trzech dróg kosztuje w Państwa przypadku mniej.