Headless Shopify – zalety i wady: kiedy własny front ma sens, a kiedy wystarczy Liquid

Rozmowa nagrana przed premierą 4 lipca 2023, więc Hydrogen, Oxygen, aplikacje i checkout w sklepie headless są opisane w stanie z tamtego momentu. Stan na październik 2026: od wersji Hydrogen 2026-10 Hydrogen jest biblioteką działającą z dowolnym frameworkiem JavaScript, Oxygen jest bez dodatkowej opłaty w płatnych planach Shopify, checkout także w sklepie headless zostaje na Shopify (rozszerza się go przez Checkout Extensibility), a Shopify nie kupił Sanity, tylko w 2022 roku zainwestował w tę firmę i nawiązał z nią partnerstwo. Sklep OPTISOFA, który podajemy jako przykład we wnioskach, był headless w 2023 roku; przy redesignie wrócił na własny motyw w Liquid: nowy sklep zaprojektowaliśmy i zbudowaliśmy w 2025 roku, a uruchomiony został w 2026. Zachował integrację z Mimeeq, a konfigurator sof modułowych przeniósł do The Planner Studio.

Klient, który chciał wrócić z headless na Liquid

Maciek: Cześć! Z tej strony Maciek Czerniak, a to jest kolejny odcinek naszego programu Flying with Shopify. Dzisiaj razem z moim wspólnikiem Kamilem zastanowimy się nad tematem headless, czyli trendu w e-commerce, który przez ostatnie parę lat zyskuje na uwadze i popularności. Zastanowimy się nad tym, kiedy to podejście do budowania e-commerce'ów jest, a kiedy nie jest dobrym pomysłem. Cześć, Kamilu.

Kamil: Witaj, Maćku.

Maciek: Nie wiem, czy przeglądasz czasami naszego HubSpota i to, co klienci do nas wypisują w zapytaniach.

Kamil: Zdarza mi się.

Maciek: Zdarza się, tak? Ostatnio trafiłem na ciekawe zapytanie, które skłoniło nas do tego, żeby nagrać dzisiejszy odcinek. Napisał do nas klient, który potrzebował przejścia z headless na Liquid, czyli ma już wdrożony headless, ale potrzebuje się cofnąć. Co się tam wydarzyło? Pisze, że agencja przekonała go do wdrożenia e-commerce'a w tym podejściu, ponieważ byłoby to bardziej kompatybilne z konfiguratorem produktu, z jego panelem klienta i jego specyficznymi wymaganiami. Natomiast z biegiem czasu po wdrożeniu okazało się, że generuje to więcej problemów niż korzyści, i chciałby zrobić krok wstecz. Wydaje mi się, że to dobry powód do rozmowy o tym, kiedy rzeczywiście powinniśmy w ten headless iść. Ale żeby odpowiedzieć na to pytanie, zacznijmy może od tego, czym w ogóle headless e-commerce czy headless Shopify jest.

Kamil: Zanim przejdziemy do tego tematu, powiem tyle, że bardzo chętnie dowiedziałbym się w szczegółach, jak wyglądał proces wyboru tego narzędzia, jak został przeprowadzony research, jak zebrano wymagania dotyczące technologii i sposobu, w jaki biznes w ogóle funkcjonuje. Bo to są ważne elementy, które determinują, czy na headless w ogóle się zdecydujemy, czy zostaniemy przy rozwiązaniu natywnym. Druga sprawa to świadomość w momencie podejmowania takiej decyzji. Wszelkie analizy i badania pomogą nam podjąć tę decyzję świadomie. Ale chyba najważniejszy morał z tej historii jest taki, że headless, pomimo tego, że, tak jak powiedziałeś, jest ostatnio bardzo popularny, jest nośnym tematem, dużo ludzi o nim mówi i pisze, wbrew pozorom nie jest remedium na wszystkie bolączki. Trzeba być tego bardzo mocno świadomym i pamiętać o tym przy wyborze headless jako rozwiązania dla nas.

Czym jest headless i architektura MACH

Maciek: Dobrze, to co, zaczniemy od początku?

Kamil: Tak, zacznijmy od początku: czym w ogóle ten headless jest? Zakasujemy rękawy i bierzemy się do roboty. Bierzemy byka za rogi. Żeby w ogóle zacząć rozmawiać o headlessie, musimy cofnąć się krok i porozmawiać o architekturze MACH, bo to coś szerszego, bardziej rozbudowanego. MACH to nazwa z czterech liter: M, A, C, H. M oznacza mikroserwisy, A podejście API first, C odnosi się do usług hostowanych w chmurze, a dopiero H jest naszym headlessem. Jak widzimy, jest to element szerszej perspektywy. Wróćmy szybciutko do każdego z tych elementów. Mikroserwisy. Myśląc o mikroserwisach, powinniśmy rozważać każdy element naszego ekosystemu jako mikrousługę, jako element większego, złożonego systemu, składającego się z wielu elementów, w którym e-commerce jest tylko jednym z nich. Mikroserwisami w naszym ekosystemie mogą być na przykład system ERP albo wspomniane w poprzednich odcinkach PIM, CRM czy chociażby CMS do zarządzania rozbudowanym modułem contentowym albo portalem społecznościowym. Dosłownie wszystko. System magazynowy, jakiś WMS. Naprawdę wszystko, co chcemy, może stanowić taką mikrousługę. A odnosi się, tak jak powiedziałem, do wykorzystania API jako kanału komunikacji pomiędzy mikrousługami. C, jak możesz się domyślić, oznacza, że możliwie wszystkie, jeżeli nie wszystkie usługi powinny być hostowane w chmurze po to, żeby zapewnić nie tylko bezpieczeństwo, ale też…

Maciek: Łatwy dostęp.

Kamil: Łatwy dostęp, performance i skalowalność, na przykład przy zwiększonym ruchu. Headless, czyli ostatni element architektury MACH, to nic innego jak rozbicie, w naszym wypadku e-commerce'a, na dwa elementy. Przy podejściu headlessowym nie korzystamy z natywnej templatki ani z templatki, którą sami zbudowaliśmy i która jest osadzona wewnątrz naszego sklepu na Shopify. Decydujemy się na to, żeby front-end odseparować i wystawić go w innym miejscu jako osobny byt, stworzony customowo przez nas.

Maciek: Front-end rozumiany jako ta część serwisu, po której porusza się użytkownik.

Kamil: Tak, dokładnie, interfejs użytkownika. Normalnie ten interfejs jest serwowany, czy mówiąc bardziej po polsku, dostarczany naszemu użytkownikowi od środka, bezpośrednio przez Shopify. Tam treść jest generowana, renderowana i dostarczana. W przypadku headlessa z tego nie korzystamy, tylko wykorzystujemy element architektury MACH, czyli komunikację po API. Odwołujemy się do naszego silnika e-commerce, żeby pewne dane pobrać, a pewne wysłać.

Wydajność i elastyczność: najczęstsze powody wyboru headless

Maciek: Jaka jest korzyść z oddzielenia warstwy frontowej od back-endu?

Kamil: Tych korzyści jest bardzo dużo. Jedną z tych, które bardzo często pojawiają się w rozmowach z naszymi klientami, jest poprawa performance'u. Mówimy o tym…

Maciek: Mam wrażenie, że to element najczęściej kojarzony z headlessem i chyba główny motywator dla wielu biznesów, żeby coś zrobić headlessowo, bo wtedy strona będzie po prostu szybsza i nie potrzeba nic więcej.

Kamil: Tak, dokładnie. Czasami ta ogromna korzyść nam wszystko przysłania, bo wzrost performance'u jest naprawdę duży. Czas potrzebny na przeładowanie strony przy przejściu z jednej zakładki do drugiej jest naprawdę bardzo krótki, dzięki czemu zyskujemy na user experience, o którym mówiliśmy w poprzednim odcinku. Doświadczenia użytkownika z korzystania z takiego serwisu headlessowego są naprawdę super.

Maciek: Okej, kontynuuj.

Kamil: Żeby plusy dodatnie nie zasłoniły nam plusów ujemnych: do wad jeszcze przejdziemy, bo, tak jak powiedzieliśmy, to rozwiązanie nie jest pozbawione minusów. Drugim najczęstszym powodem, żeby w ogóle rozważyć headless, jest elastyczność. To naprawdę fakt i warto na to zwrócić uwagę. Wspomnieliśmy, że możemy mieć kilka mikroserwisów, kilka elementów naszego ekosystemu, i że sami decydujemy się na zbudowanie naszego interfejsu użytkownika, czyli front-endu. Załóżmy, że mamy sklep, a w zupełnie innym narzędziu, na innym CMS-ie, mamy bardzo rozbudowanego bloga, dosłownie portal społecznościowy. Ale zostańmy przy blogu. Może się okazać, że posadzenie bloga na subdomenie nie spełnia naszych oczekiwań biznesowych czy funkcjonalnych. Chcemy mieć wszystko w jednym miejscu: treści przeplatane produktami albo odwrotnie, kartę produktu wzbogaconą o treści związane z danym produktem, na przykład wszelkiego rodzaju poradniki. Jeżeli sprzedajemy produkty specjalistyczne, jest to jak najbardziej pożądane. Jeden element na domenie głównej, a drugi na subdomenie nie pozwoli nam tego zrobić. Kiedy zdecydujemy się na zbudowanie własnego frontu, możemy dowolne elementy, w dowolnej formie, pobrać jednocześnie z e-commerce'a i z naszego CMS-a, a potem w dowolny sposób je poukładać i wyświetlić użytkownikowi. Więc ta elastyczność jest naprawdę bardzo duża.

Maciek: Okej, ale rozumiem, że mówimy tu o sytuacji, w której potrzebujemy czerpać dane z kilku różnych źródeł. Wydaje mi się, że jeżeli mamy do wyświetlenia tylko rzeczy ze sklepu, czyli produkty, zdjęcia, opisy i wszystko, co jest przechowywane przez Shopify, to raczej nie ma żadnych ograniczeń w budowaniu warstwy frontowej. Przynajmniej ja ich tu nie widzę.

Kamil: Do pewnego momentu tak. Natomiast jeżeli mamy potrzebę, żeby nasza ingerencja poszła jeszcze krok dalej, nawet w obrębie tego jednego narzędzia, na przykład własny, w pełni scustomizowany checkout, to wtedy będziemy zachęceni, żeby pójść w kierunku rozwiązania headlessowego.

Aplikacje i integracje w sklepie headless

Maciek: Okej. A w kontekście tej elastyczności: co z różnymi integracjami, które już mamy?

Kamil: To bardzo ciekawe zagadnienie. Skalowalność i elastyczność są wymieniane jako oczywiste, wręcz fundamentalne korzyści headlessa. Natomiast jest tu mała pułapka. Shopify w podejściu out of the box, czyli natywnym, dostarcza nam sam z siebie pewne elementy, struktury danych, komponenty. Korzystając z podejścia templatkowego, kiedy mamy skórkę zaprojektowaną przez nas albo kupioną w sklepie z szablonami, te komponenty, moduły i funkcjonalności są dla nas dostępne w bardzo prosty sposób. Jeżeli natomiast wyjdziemy z tego obszaru i zdecydujemy się na headless, musimy zdawać sobie sprawę z tego, że wszelkiego typu apki, moduły i dodatki, które kupimy do naszego sklepu, niestety nie będą działać. Wynika to bezpośrednio z tego, że, jak powiedzieliśmy już co najmniej dwa razy, do komunikacji między naszym storefrontem a zapleczem sklepu, czyli silnikiem Shopify, korzystamy z API. A te aplikacje nie są dostępne z tego poziomu, nie są dostępne w API.

Maciek: Więc jeżeli chcemy włączyć Klaviyo, inne narzędzie do automatyzacji marketingu czy jakąkolwiek inną aplikację, to mamy problem.

Kamil: Będziemy w stanie to zrobić, ale nie w tak szybki i sprawny sposób.

Maciek: Musimy to napisać od zera.

Kamil: Tak, dokładnie. Musimy sami przeprowadzić taką integrację.

Czy headless jest „future proof”?

Maciek: Okej. Często pojawia się argument, że rozwiązania headless są future proof, czyli odporne na to, co będzie się działo w przyszłości.

Kamil: Ja nie do końca się z tym zgadzam. Wiem, że to nie jest prosta sprawa i nie da się tego ująć w jednym zdaniu, mówiąc tak lub nie. Podejście headless czy w ogóle architektura MACH opiera się na wielu elementach. Taka modularyzacja, rozbicie na pojedyncze elementy sprawia, że jeżeli chcemy zaktualizować jakiś obszar, to zazwyczaj wprowadzamy usprawnienia w jednym czy dwóch komponentach. Możemy też myśleć o korzyściach z tego, że dostawcy poszczególnych narzędzi i technologii będą je rozwijać, a my na tym zyskamy. Dlaczego jednak nie wydaje mi się to takie czarno-białe? Bo widzimy, jak szybko i w jakim zakresie Shopify rozwija swój własny silnik. Rozwija nie tylko sam core, ale dodaje szereg nowych funkcjonalności. Poza tym bardzo uważnie słucha swoich użytkowników. Trzeba przyznać, że są naprawdę świetni w obserwowaniu potrzeb rynku, więc dobrze idzie im dostarczanie dodatków, usprawnień i nowych elementów. Jestem tu raczej spokojny o to, jak będzie wyglądała przyszłość i czy te potrzeby będą zaspokajane. To nie jest takie czarno-białe, że headless jest gwarancją, a bez niego będziemy mieli problem.

Maciek: Warto też wspomnieć, że Shopify jest super przygotowany pod podejście headless, bo do wszystkiego mamy API i możemy się fajnie komunikować ze wszystkimi obszarami e-commerce. Druga sprawa: Shopify sam mocno inwestuje w to podejście i rozwija własne rozwiązania i usługi wokół headless. Mam tu na myśli Hydrogen, Oxygen czy zakup jakiś czas temu CMS-a Sanity.

Kamil: Dokładnie, ale świadczy to o dwóch rzeczach. Po pierwsze o tym, że headless rzeczywiście jest nośnym tematem. Wynika to bezpośrednio z potrzeb rynku. Biznesy są coraz bardziej skomplikowane, usług jest coraz więcej. Potrzebujemy łączyć i integrować ze sobą bardzo różne elementy, a dane wyświetlane na storefroncie mogą pochodzić z różnych miejsc. A po drugie o tym, że są naprawdę dobrymi obserwatorami i aktywnie dbają, żeby ich produkt był cały czas na czasie. Uruchomienie podejścia headlessowego w ramach Shopify jest tylko dowodem na to, że rynek potrzebuje tego rozwiązania.

Maciek: Wydaje mi się, że to wynika też trochę ze strategii direct to customer, którą wdraża Shopify, w sensie prowadzenia sprzedaży tam, gdzie jest klient. Z jednej strony to oczywiście inwestowanie w sprzedaż w różnych kanałach social media, czy to na YouTubie, Pintereście, TikToku i tak dalej. Ale z drugiej strony podejście headlessowe daje nam możliwość, i to chyba zabrzmiało już na początku, że storefrontem niekoniecznie musi być sklep internetowy. To mogą być inne rzeczy.

Kamil: Dokładnie. Najlepszym przykładem może być aplikacja mobilna, i mówimy tu o natywnej aplikacji, nie o stronie RWD. Tak jak powiedziałeś, storefrontem jest wtedy po prostu natywna aplikacja zainstalowana na telefonie, a silnikiem e-commerce'owym, czyli tym, co w tle przeprowadza całą transakcję, może być właśnie Shopify.

Maciek: To mogą być też wearables, różne smartwatche, kioski, infokioski czy asystent głosowy. Czekam na to, w jaki sposób będzie można robić zakupy przez ChatGPT czy inne narzędzia sztucznej inteligencji.

Kamil: Dokładnie tak. Do tej bardzo długiej listy można jeszcze dołożyć na przykład platformy, które umożliwiają zakupy w wiadomościach tekstowych. Zwykłym SMS-em można potwierdzić ofertę, którą dostajemy SMS-em, i w ten sposób zamówić produkt, który kupujemy często. Spodziewamy się, że miesiąc po ostatniej transakcji dostawca zapyta nas, czy znowu nie chcemy kupić danego produktu.

Dowolność technologii a limity API

Maciek: Okej. Argumentem, który też często pojawia się w rozmowach o headlessie, jest dowolność technologii. Mam wrażenie, że podnoszą go głównie deweloperzy: dzięki temu mogą zrobić frontend w tym, w czym chcą, i niekoniecznie muszą się uczyć Liquida, który akurat jest relatywnie prosty do nauczenia się. Ale taka uwaga często się pojawia. Co o tym myślisz?

Kamil: Na pewno jest w tym trochę racji, ale wydaje mi się, że kluczowy jest powód powstania takiej opinii. Shopify jako narzędzie SaaS ma swoją architekturę, swoje wymagania, ale też ograniczenia. Działanie w tej relatywnie zamkniętej przestrzeni może powodować pewien dyskomfort u naszych kolegów i koleżanek i może dlatego chętniej sięgają po narzędzia bardziej otwarte. Chciałbym jednak zaznaczyć, że przechodząc do architektury otwartej, nie możemy skorzystać z dobrodziejstw, które dają produkty SaaS. Przykładów jest wiele, ale jednym jest dostęp do pewnych obiektów. Na przykład wyświetlenie wszystkich produktów w Shopify przy podejściu natywnym jest operacją wręcz banalną, a przy podejściu headless musimy zwracać uwagę na limit operacji, które API jest w stanie obsłużyć w jednostce czasu. Także to nie jest takie czarno-białe.

Maciek: Wydaje mi się, że Shopify stara się rozwiązać te problemy, o których mówisz, oferując swój framework headless Hydrogen, który ma, bo to się zmienia, coraz więcej wspólnego z metodami Liquida i ma dostęp do tych obiektów.

Kamil: Na pewno będzie to rozwiązanie, które połączy te dwa światy. Z jednej strony będziemy mieli rozwiązanie firmowane przez Shopify, więc można się spodziewać, że będzie miało więcej metod i możliwości dostępu do danych niż obecnie API, a z drugiej wykorzysta elastyczność i swobodę działania, której doświadczamy, korzystając z innych technologii headlessowych.

Wady headless: czas, koszt, programiści i hosting

Maciek: Okej, porozmawialiśmy trochę o korzyściach z headlessa i mam nadzieję, że udało nam się pokazać, że to, co czasem jawi się jako oczywista korzyść, ma swoje drugie dno i często nie jest jednoznaczne. Chciałbym, żebyśmy teraz porozmawiali o drugiej stronie, czyli o wadach tego rozwiązania. Myślę, że możemy zaspoilować, że nie jest to takie czarno-białe i trzeba po prostu uwzględnić, że wszystko zależy od kontekstu, w którym jesteśmy.

Kamil: Na pewno jest tak, jak mówisz: nie ma narzędzia idealnego i po raz kolejny to powiemy, headless takim narzędziem nie jest. Chociażby ze względu na swoją złożoność wymaga więcej czasu na development. Jak powiedzieliśmy, niektóre moduły są niedostępne, nie możemy korzystać z dobrodziejstw produktu SaaS-owego i wszystko musimy zrobić własnymi rękami. Dlatego czas potrzebny na stworzenie takiego sklepu jest dłuższy niż przy podejściu natywnym. A jeżeli czas, to automatycznie koszt: możemy się spodziewać, że ta inwestycja pochłonie więcej środków. Dodatkowo Shopify przy podejściu natywnym jest rozwiązaniem, które, jak powiedziałeś wcześniej, można zrobić prawie samemu, przy pewnej znajomości narzędzia i ogólnej wiedzy technologicznej. Są nawet sklepy, które powstały z udziałem osób niezwiązanych z branżą IT. Przy headless niewątpliwie będziemy potrzebowali programistów. Programistów, którzy mają odpowiedni skill set i doświadczenie komercyjne, potrafią zbudować taką rozbudowaną architekturę i poradzić sobie z nią. W związku z tym możemy się spodziewać, że nakład finansowy, chociażby na ich wynagrodzenie czy zatrudnienie, będzie dużo wyższy niż przy podejściu natywnym. Mamy tu więc co najmniej kilka aspektów stricte finansowo-biznesowych, które trzeba wziąć pod uwagę.

Maciek: Pewnie dochodzi też kwestia infrastruktury. Jeżeli stawiasz storefront headlessowy, to póki co stawiasz go przeważnie u siebie, na swoim hostingu, więc musisz się martwić o ten hosting, o jego bezpieczeństwo, o to, żeby utrzymał większy ruch. Chyba że decydujesz się na rozwiązanie, które oferuje Shopify, czyli Oxygen.

Kamil: Okej, ale załóżmy, że się na nie nie decydujemy. A nawet jeśli, to i tak zostaniemy obarczeni dodatkowymi kosztami, bo to kolejny aspekt, który rzeczywiście będzie widać w naszym budżecie. Tak jak powiedziałeś, decydując się na headless, musimy zapewnić sobie hosting. Będziemy musieli się o niego martwić, monitorować go, dbać o to, żeby działał i żeby uptime był jak najwyższy. Dostawcy oczywiście to zapewniają, ale najważniejsze jest chyba to, i trzeba to jasno powiedzieć, że zmartwienie jest mocniej przesunięte w naszą stronę. Przy podejściu natywnym Shopify bardzo mocno dba o wszystko i naszych zmartwień jest mniej. Możemy się wtedy skupić na tym, co w danym momencie rzeczywiście jest ważne dla naszego biznesu.

SEO w sklepie headless

Maciek: Mówiliśmy o kompatybilności z aplikacjami Shopify, o tym, że de facto nie możemy korzystać z dobrodziejstw, tak to nazwijmy, które daje nam Shopify w postaci time-to-market i wdrażania różnych funkcjonalności. Jak wygląda sytuacja, jeśli chodzi o pozycjonowanie, czyli search engine optimization, SEO?

Kamil: Tutaj, wbrew niektórym opiniom, wydaje mi się, że przy podejściu headlessowym mamy dużo większą szansę zrobić to tak, jak wymaga tego nasz biznes i jak chcemy. Pracując w podejściu natywnym, operujemy w ramach pewnej struktury, pewnej architektury. Markup, który potem analizują roboty, jest do pewnego stopnia ograniczony. Ma swoją strukturę.

Maciek: Struktura linków. Nie możemy jej zmienić.

Kamil: Tak, dokładnie. Przechodząc od markupu do struktury linków, czyli też elementu dość istotnego z punktu widzenia SEO, napotkamy co najmniej kilka ograniczeń. W podejściu headlessowym mamy pełną dowolność i sami możemy zdecydować, jakie rozwiązanie będzie dla nas najlepsze. Także wbrew niektórym opiniom uważam, że SEO przy podejściu headlessowym może zostać zrobione naprawdę dużo lepiej.

Zalety szablonu Shopify w Liquid

Maciek: Dobrze, to spróbujmy jeszcze zestawić headlessa z tradycyjnym podejściem, czyli szablonem Shopify zbudowanym w oparciu o język Liquid. Jakie korzyści oferuje z kolei to rozwiązanie? Zakładam, że to będzie w pewnym sensie odwrócenie tego, o czym mówiliśmy przy headlessie, ale może coś jeszcze.

Kamil: Dokładnie, żeby nie demonizować tego rozwiązania i nie traktować go jak pomiotu szatana. Warto wymienić kilka najważniejszych zalet. Tak jak powiedziałem, może nie super jasno: przy podejściu natywnym sklep można postawić własnymi siłami. Uruchomienie sklepu, dodanie kilku produktów, kupienie szablonu, który spełnia nasze oczekiwania finansowe, oczekiwania…

Maciek: Budżetowe.

Kamil: Budżetowe lub wizualne. Zainstalowanie go w sklepie, dodanie bramki płatności, z którą akurat mamy podpisaną umowę, i dosłownie w ciągu jednego weekendu można uruchomić sprzedaż. Znamy takie przypadki z naszej historii, więc jest to totalnie możliwe. Robimy to sami i bardzo szybko. Mamy wszystko w jednym miejscu i nie musimy się martwić o oczywiste funkcjonalności, jak filtrowanie czy strony kategorii. Cała masa rzeczy jest dostarczona, tak jak powiedziałem, out of the box. I, będąc zupełnie szczerym, relatywnie tanio, bo abonamenty nawet na najbardziej podstawowe pakiety Shopify są naprawdę niskie. Zakup templatki to też maksymalnie kilkaset dolarów i jest to wydatek jednorazowy. Więc po stronie budżetowej wygląda to naprawdę bardzo dobrze.

Maciek: No dobra, przejdźmy dalej. Wydaje mi się, że korzyścią jest też, czasami korzyścią, a czasami problemem, to, że w podejściu liquidowym możesz zarządzać wszystkim w jednym miejscu.

Kamil: Tak, rzeczywiście. Zarówno bazą produktów, jak i stronami contentowymi, jeżeli są oparte na silniku Shopify, zarządzamy w jednym miejscu. Jeżeli jesteśmy na początku swojej ścieżki biznesowej jako młody czy początkujący sprzedawca, to prawdopodobnie nie będziemy mieli takich narzędzi jak PIM, CRM, ERP. Nie będziemy zintegrowani z żadnym magazynem ani dostawcą usług kurierskich, więc nasz ekosystem jest mały. W związku z tym nie widzę w zasadzie żadnego powodu, żeby go sztucznie komplikować.

Maciek: Dobrze. Możemy jeszcze wspomnieć, że w jakimś sensie podejście liquidowe uniezależnia nas trochę od deweloperów. Jesteśmy w stanie dużo rzeczy zrobić samodzielnie.

Kamil: Tak. Wsparcia ze strony osób zewnętrznych potrzeba na pewno mniej. Programiści mogą nam być potrzebni wtedy, kiedy chcemy wyjść poza to, co Shopify dostarcza sam z siebie. Myślę, że na pewno warto mieć kogoś zaprzyjaźnionego, kto pomoże nam chociażby w budowaniu sklepu, nawet w podejściu natywnym. Natomiast udział tej osoby będzie na pewno dużo mniejszy niż przy tak zwanym headlessie.

Kiedy headless ma sens, a kiedy zostać przy Liquid

Maciek: Dobra, myślę, że możemy spróbować to podsumować, zamknąć klamrą i dojść do wniosków. Wróćmy do klienta z początku odcinka. Czym powinien się kierować, żeby podjąć dobrą decyzję? Czy powinien iść w headless, czy na tym etapie rozwoju zostać jednak przy Liquidzie?

Kamil: Odpowiadając na to pytanie, chciałbym wykorzystać swoje ostatnie doświadczenia z kilkoma naszymi klientami oraz to, co już powiedzieliśmy o obu rozwiązaniach. Żeby to spiąć, zacząłbym od tego, że kluczowe pytanie, które zawsze zadaję klientowi, brzmi: czy jego biznes jest już na takim etapie, że potrzebuje headlessa? Jak wygląda jego ekosystem? Z jakich zewnętrznych narzędzi korzysta, a z jakich…

Maciek: To bardzo ważne: z jakich będzie korzystał w przyszłości. Analiza tego, gdzie jesteśmy dzisiaj, i tego, gdzie będziemy za jakiś czas, jakie są nasze plany i ambicje biznesowe, jest naprawdę bardzo istotna, żeby świadomie podjąć decyzję o może nawet trochę wcześniejszym wdrożeniu headlessa, dzięki czemu nie będziemy musieli robić tego dwa razy. Jeżeli jednak takie perspektywy nie są do końca jasne, jeżeli klient nie ma jasno zdefiniowanego planu albo nie wie dziś, że będzie potrzebował jakiegoś rozwiązania, to można wykorzystać podejście natywne, na przykład szybciej wejść na rynek, szybciej zwalidować produkt i koncepcję biznesową, a środki zaoszczędzone na podejściu natywnym wykorzystać chociażby na marketing.

Kamil: Czyli na to, żeby dotrzeć do klientów i zapewnić sobie większy wolumen sprzedaży.

Maciek: Możemy więc powiedzieć jako konkluzję, że Shopify headless nie jest rozwiązaniem dla każdego. Nie jest też tak, że jest tylko dla dużych graczy. Zależy to od konkretnego momentu, w którym jesteś jako firma. Wydaje mi się, że wniosek jest taki: czasami headless spowolni cię operacyjnie jako biznes, czasami cię przyspieszy, i trzeba wyczuć tę granicę, moment, w którym dokonać przejścia.

Kamil: Tak, dokładnie. Tak jak powiedziałeś, w niektórych sytuacjach headless może być dla biznesu overkillem. Jesteśmy młodą, dopiero rozwijającą się marką, wręcz wchodzimy na rynek, a od razu skazujemy się na to, żeby zaistnieć w przestrzeni publicznej dopiero kilka długich miesięcy po decyzji o budowie e-commerce'u. A przy podejściu natywnym możemy to zrobić w kilka tygodni, być na rynku dużo szybciej i walczyć o klienta. Więc, jak powiedzieliśmy, trzeba sobie odpowiedzieć na pytanie, które z tych dwóch narzędzi, a każde ma swoje wady i zalety, jest dla mnie w tym momencie bardziej odpowiednie.

Maciek: Mnie się wydaje, że headless jest jednak rozwiązaniem dla firm, które są już dość dobrze rozkręcone, generują gdzieś pół miliona dolarów obrotu miesięcznie, mają odpowiednią złożoność techniczną, własne zasoby i na tyle złożone procesy biznesowe, że wtedy jest sens to robić. Jeżeli chodzi tylko o szybkość działania strony, to na pewno jest to overkill.

Kamil: Zdecydowanie tak. Oczywiście nie jest to reguła, ale na pewno tendencja, że headless dużo lepiej sprawdzi się u klientów, którzy mają już ugruntowaną pozycję na rynku i bardziej skomplikowane procesy biznesowe, rzeczywiście potrzebują integracji wielu narzędzi i chcą podnieść swój biznes na wyższy poziom.

Maciek: Bo na rynku możemy obserwować szereg ogromnych firm, enterprise'ów. Był ten Giant Tiger, który niedawno zmigrował się na Shopify i zrobił to w podejściu liquidowym, bo mają naprawdę dosyć prostą logikę. Mają produkt, wysyłają go z magazynu, koniec tematu, i nie oferują nic skomplikowanego.

Kamil: I bardzo dobrze, że tak zrobili. Nie silą się na rozwiązania, które nie będą miały zwrotu z inwestycji. To naprawdę bardzo świadome, wręcz pragmatyczne podejście. I ja zawsze zachęcam klientów, z którymi mam przyjemność pracować, żeby właśnie takim pragmatyzmem wykazywali się przy podejmowaniu tej decyzji.

Maciek: Dobrze, Kamil, dziękuję ci bardzo za rozmowę. Mam nadzieję, że udało się przybliżyć słuchaczom i widzom temat headless e-commerce.

Kamil: Również dzięki. Dziękuję za wasz czas.

Maciek: A wam również dziękuję za czas. Zapraszam do słuchania i oglądania kolejnych odcinków. Dział marketingu kazał mi zaprosić was do obserwowania tego kanału tam, gdzie jest dostępny, co niniejszym czynię. Dzięki i do zobaczenia. Usłyszymy się.