Wróć do realizacji

Lactee – sklep dla producenta kosmetyków

Marek KoncewiczMarek Koncewicz
1 lutego 20264 min czytania
Lactee – sklep dla producenta kosmetyków

W skrócie

Zbudowaliśmy sklep lactee.pl oparty na WooCommerce z dedykowanymi banerami, newsletterem i blogiem.

Ile kosztuje postawienie sklepu

Na początku 2025 roku dostałem wiadomość od znajomej: „Marku, chcemy sklep postawić. Jaki to będzie koszt?".

Padło też pytanie o terminy. Wytłumaczyłem, że chętnie zapoznamy się z przygotowanymi przez klienta widokami, dopytamy o wymagania, przeanalizujemy zebrane dane i wtedy będziemy w stanie oszacować pracochłonność.

To był ten klient, który oprócz swojej głównej działalności w branży kosmetycznej posiadał również ekspertyzę w obszarze designerskim. Dzięki temu przy pierwszym kontakcie od razu dostaliśmy przygotowane przez doświadczonego grafika widoki przyszłego sklepu, osadzone w Figmie.

Mieliśmy dodatkowo kilka spotkań na temat mechaniki sklepu. Które elementy mają być na stałe, które dynamiczne, jakie oczekiwania mają co do technologii. Dopiero po uwzględnieniu wszystkich niuansów, po rozmowie z menedżerem projektu i grafikiem, który zaprojektował sklep, byliśmy w stanie podać termin oddania sklepu oraz łączną cenę.

Koszt budowy tego rodzaju sklepu, z niewielką liczbą produktów, oparty na WooCommerce, z możliwością opłaty zamówień online, newsletterem i ze wstępnie przygotowanym designem po stronie klienta, zaczyna się od 30 tys. zł netto.
Widoki sklepu osadzone w Figmie

Technologia

Wymaganiem klienta było zbudowanie sklepu na technologiach z otwartym kodem źródłowym. Zaproponowaliśmy PrestaShop. Przyszli administratorzy sklepu posiadali doświadczenie w obsłudze WooCommerce, co ostatecznie zdecydowało o wyborze.

Tłumaczyliśmy klientowi, że WordPress nie jest lepszym rozwiązaniem. Argumentowaliśmy złożonością wdrożenia i utrzymania. Silnik ten został zbudowany wiele lat temu, kiedy systemy kontroli wersji nie były tak spopularyzowane jak dziś, a wdrożenie na produkcję odbywało się poprzez pojedyncze wgrywanie odpowiednich plików na serwer przez FTP.

Jednak posiadanie ekspertyzy w zakresie zarządzania WooCommerce przeważyło nad naszymi argumentami i zabraliśmy się za prace projektowe.

Analiza

Podczas prac architektonicznych szukaliśmy odpowiedzi na pytanie: jak doprowadzić technologię wybraną przez klienta do poziomu rozwiązania klasy enterprise? Pytanie słuszne, ponieważ nie chcieliśmy zostawić klienta na lodzie po wdrożeniu i zamierzaliśmy utrzymywać ten projekt w ramach Koncewicz Software House.

Szukaliśmy podejścia, przy którym moglibyśmy skorzystać z dobrych praktyk:

  • Konteneryzacja
  • Śledzenie zmian w kodzie źródłowym
  • Wykorzystanie menedżera pakietów
  • Nowoczesne technologie frontendowe

WordPress nie posiada żadnej z tych właściwości.

Należało znaleźć rozwiązanie, które umożliwi połączenie wymagań klienta z naszą wizją architektoniczną.

Bedrock

Na stronie projektu Bedrock znajdziemy taki opis:

WordPress boilerplate z Composerem i Gitem, łatwiejsza konfiguracja oraz ulepszona struktura folderów

Tłumacząc na ludzki język, ten projekt rozwiązuje 3 z 4 problemów, które opisałem wyżej: konteneryzację, wersjonowanie kodu oraz użycie menedżera pakietów.

Bez tych właściwości nie jesteśmy w stanie zapewnić stabilności projektu na poziomie enterprise. Bez nich otrzymamy wydłużone procesy dostarczania nowych funkcjonalności, problemy z podbiciem wersji WordPressa, braki wiedzy o projekcie.

Bedrock podszedł do tematu radykalnie. Odpalili własne repozytorium pakietów zgodne ze standardem Composer i skopiowali do niego większość pluginów WordPressa (w tym WooCommerce). W repozytorium projektu znajdują się pliki inicjalizacyjne. Od razu po sklonowaniu projekt odpowiada wymaganiom enterprise.

Headless

Bedrock rozwiązał kwestie backendowe. Pozostaje zaś kwestia frontendu. Naszą wizją było użycie nowoczesnych technologii, takich jak VueJS, Tailwind oraz SSR. Bedrock nie rozwiązuje tego problemu z pudełka.

Pod tym kątem wyręcza nas sam WordPress. W ostatnich wersjach silnika dostępne jest Store API, które umożliwia zarządzanie koszykiem, składanie zamówień czy listowanie produktów z poziomu API. Te operacje są dostępne dla anonimowego użytkownika.

Po wstępnych testach otrzymaliśmy potwierdzenie: idea headless jest jak najbardziej realna. Da się zbudować nowoczesny sklep, pod spodem którego znajduje się WooCommerce.

Headless to architektura oprogramowania, która umożliwia zbudowanie odrębnej warstwy aplikacji, występującej w roli pośrednika między użytkownikiem a centralną aplikacją. W naszym przypadku – sklepem.
Własna implementacja okna wyboru punktu odbioru – zamiast gotowego widgetu Furgonetki

Wooless

Przed startem prac bezpośrednio nad sklepem klienta stworzyliśmy demo, zawierające WordPress z niezbędnymi wtyczkami, warstwę frontendową i wszystkie technologie niezbędne do postawienia nowoczesnego sklepu online.

Projekt został umieszczony na GitHubie pod nazwą Wooless. To zestaw gotowych skryptów, kontenerów, wtyczek i struktury plików, umożliwiający utrzymanie sklepu zgodnie z dobrymi praktykami. Demo projektu umieściliśmy pod linkiem sklep.wooless.pl.

Demonstracyjny sklep ilustruje, jak duże korzyści czerpie zespół projektowy, realizując architekturę typu headless. Oto niektóre z nich:

  • Płynne przejścia między stronami
  • Nowoczesne technologie frontendowe
  • Niemal nieograniczone możliwości optymalizacji
  • Pełna kontrola nad UI/UX każdego elementu sklepu

Tak radykalne podejście może się wydawać marnowaniem zasobów. Faktycznie, poświęciliśmy dużo czasu na analizę, planowanie i dobór narzędzi. Wolę jednak to podejście, bo alternatywą jest zrealizowanie projektu tylko w 80–90% zgodnie z początkowym pomysłem projektanta graficznego.

Nie ma opcji, by osiągnąć 100% spójności z makietą projektu, jeśli nie mamy pełnej kontroli nad każdym obszarem sklepu. Presja czasu, wykorzystanie zewnętrznych wtyczek, pokusa rozpoczęcia kodowania projektu tu i teraz prowadzą do sytuacji, w której dowiezienie ostatnich 20%, 10% czy 5% projektu jest po prostu niemożliwe. Jeśli próbujemy docisnąć te ostatnie procenty spójności za pomocą wątpliwych praktyk programistycznych, efekt końcowy nie będzie satysfakcjonujący. Użytkownik nie będzie miał chęci korzystania z takiej strony.

Podsumowanie

Dostarczyliśmy klientowi rozwiązanie w 100% zgodne z jego oczekiwaniami oraz spójne z myślą osoby od designu sklepu. Wypracowaliśmy podejście, przy którym sklep korzysta z rozwiązań opartych na otwartym kodzie źródłowym (wymaganie klienta) oraz jest nowoczesny, szybki, stabilny i poprawnie działa na komórkach, tabletach i dużych ekranach desktopowych.

Marek Koncewicz
Marek KoncewiczFullstack Engineer

Ewangelista Laravela. Zwolennik produktowego podejścia do rozwoju aplikacji webowych.