Garten Chemie GmbH — niemiecki e-commerce chemii ogrodniczej, 18 lat na rynku, ~50 000 zamówień rocznie. Klient zgłosił się z konkretnym problemem: ekipa magazynowa traci 30 minut dziennie na pakowaniu z papierowych list, error rate ~3%, brak audit trail.
Discovery call ujawnił dalej: peak day = 140 zamówień, 4 osoby na magazynie, brak żadnego systemu integrującego się z WooCommerce poza ręcznym CSV export. Drukarka termiczna już stała w kącie — kupiona „kiedyś tam” pod plan który nigdy nie wystartował.
Kontekst klienta
Garten Chemie używa standardowego stacku DACH: WooCommerce + Germanized + Astra Pro hostowane na Hetzner CPX32. 50k orderów rocznie to średnio ~140 dziennie w peak season (kwiecień-czerwiec, sezon ogrodowy). Magazyn ma 4 osoby pracujące na 2 stacjach pakowania, ośmiogodzinna zmiana.
Klient sformułował cztery wymagania:
- Dashboard pakowania który eliminuje papier — żadnego drukowania list pickingu, wszystko na tablecie.
- Audit trail per packer — kto spakował, kiedy, jakie SKU, czas spędzony na zamówieniu.
- Integracja z drukarką termiczną — etykieta wysyłkowa + paragon Lebensmittelangaben drukowane jednym tapem.
- Offline support — magazyn ma słabe WiFi w głębi hali, system musi przeżyć 10-30 minutowy outage bez utraty progressu.
Brief i scope
Discovery call odbył się 14.04.2026. Przylecieliśmy na jeden dzień do siedziby klienta w Hamburgu — obserwacja w magazynie była nie do zastąpienia żadnym Zoom call’em. Średni czas pakowania mierzony stoperem: 4-5 minut na zamówienie. Error rate ~3% (zwykle złe SKU lub brakujące pozycje), wykrywany dopiero przez customer service po reklamacji.
Scope agreement domknęliśmy w trzech dniach: 4 fazy, budżet 12 000 PLN flat rate, 6-tygodniowy delivery window, fazy 1-5 zamknięte przed sezonem.
Stack: custom plugin, nie SaaS
Klient przed kontaktem z nami miał oferty od dwóch SaaS providers: ShipStation (US) i Picqer (NL). Oba dojrzałe produkty, oba z dobrymi recenzjami DACH. Powody dla których odrzuciliśmy SaaS i zarekomendowali custom plugin:
- Lock-in. Jeśli SaaS upadnie albo podniesie ceny 3×, klient jest w pułapce. 50k orderów rocznie to za dużo żeby migrować na cito.
- Integracja z Germanized. SaaS musiałby pull/push przez REST API — double source of truth. Custom plugin operuje natywnie na
wc_get_order(). - Customizacja. ShipStation nie wie czym jest Inhaltsstoffe-Pflichtangabe dla detergentów.
- Cena. ShipStation $99/mc × 12 = $1188/rok × 5 lat = ~25 000 PLN. Custom plugin 12k one-off = breakeven po 2 latach.
Implementacja faz 1-5
Plugin powstał w ~1100 linii PHP + ~600 linii JS. Świadomie trzymaliśmy się jednej klasy per koncept (GCPD_Orders, GCPD_Session, GCPD_PDF, GCPD_Auth, GCPD_API). Żadnego frameworka, żadnego service containera. Plugin który ktoś inny zrozumie w 30 minut, bo to plain PHP.
Decyzja jQuery zamiast React’a wymagała obrony. Standard 2026 byłby React + Vite + WP REST + WP nonce auth. Ale tablet w magazynie Garten Chemie to Samsung Galaxy Tab A7 kupiony w 2021, Chrome 92 jako maximum. React 18 z modern bundle = polifillami napompowany 800 KB. jQuery 3.7 + ręcznie napisane vanilla = 42 KB gzipped, ładuje się w 280ms na 3G.
Co poszło źle (Faza 5b)
Shake-out test na real prod data wykrył 5 bugów: 3 critical, 2 minor + 4 UX tweaks. Najgorszy: Redis cache shared namespace między prod i staging klonem — staging URL wyciekał do prod cache, /wp-admin/ redirectowało na staging aż do wp cache flush. Memory lesson: zawsze zmieniać WP_CACHE_KEY_SALT przy klonowaniu.
Wnioski + co inaczej
Klient ma teraz: 30% szybsze pakowanie, error rate <0.1%, zaoszczędzone ~125h/rok (1 FTE × 6 tyg freed). Plugin działa offline (localStorage state sync), PDF audit per sesja, integracja z drukarką termiczną — wszystko za 12k PLN one-off zamiast €180/mc lifetime SaaS lock-in.
Co inaczej następnym razem: jeden dzień on-site przed scope agreement obowiązkowy. Zoom call mówi 60% prawdy o magazynie. Pozostałe 40% widać tylko fizycznie.