Zauważono braki w procesie płatności, panelu administracyjnym lub realizacji zamówień. Do piątku w skrzynce odbiorczej lądują trzy opcje: miesięczna subskrypcja aplikacji, stała wycena od freelancera oraz oferta agencji, która najpierw chce przeprowadzić warsztaty odkrywcze. To rozwidlenie to prawdziwa decyzja: kupić czy zbudować aplikację ecommerce – a nie debata filozoficzna. Poniższa lista kontrolna jest przeznaczona na jedno posiedzenie, aby po spotkaniu mieć wybraną domyślną ścieżkę zamiast kolejnego tygodnia wymieniania wiadomości na Slacku.
Poniżej znajduje się wyjaśnienie, co oznacza kupowanie i budowanie w działającym sklepie, kiedy każde z tych rozwiązań wygrywa, kiedy warto poprosić dostawcę o drobną funkcję, pomijane koszty, karta ocen do druku oraz trzy krótkie scenariusze. Żadnego nakłaniania do wynajęcia nas – po prostu sposób na dokonanie wyboru bez zgadywania.
Co w praktyce oznacza wybór: kupić czy zbudować aplikację ecommerce w działającym sklepie
Na platformach Shopify, PrestaShop lub WooCommerce, „kupno” zazwyczaj oznacza aplikację z marketplace, moduł lub wtyczkę, którą się instaluje, konfiguruje i opłaca w formie subskrypcji lub jednorazowej licencji. „Budowanie” oznacza niestandardowy kod – prywatną aplikację, dedykowany moduł, nadpisanie szablonu lub warstwę pośrednią – napisany pod konkretny przepływ pracy. W praktyce licząca się alternatywa leży pośrodku: mocne skonfigurowanie gotowego produktu (zatrzymując się przed modyfikacją kodu dostawcy) lub poproszenie dostawcy o dodanie brakującego elementu do jego rozwiązania.
Podejście Harvard Business Review dla firm średniej wielkości jest tutaj również przydatne: wybór to nie tyle „co jest moralnie lepsze”, ale raczej czy brakujący element to powszechny problem, czy też coś, co powinno pozostać unikalne dla danej firmy. Szersze spojrzenie na ten temat można znaleźć w artykule When Should Your Company Develop Its Own Software?. Jednak zespoły zarządzające e-handlem wciąż potrzebują listy kontrolnej dostosowanej do specyfiki sklepów internetowych.
Kiedy wygrywa gotowe rozwiązanie
Kupno to najlepsza opcja, gdy problem jest powszechny, aplikacja jest na bieżąco dostosowywana do aktualizacji platformy, a odinstalowanie stanowi realną drogę wyjścia. Silne sygnały: kilka renomowanych aplikacji już opisuje podobny przypadek użycia w swojej ofercie; w recenzjach pojawiają się wzmianki o używanej wersji systemu; wsparcie odpowiada w ciągu dni, a nie wcale; istnieje możliwość przetestowania narzędzia na wycinku zamówień lub w środowisku testowym (staging).
Kupowanie wygrywa również wtedy, gdy szybkość ma większe znaczenie niż unikalność – szczyt sezonu za sześć tygodni, uruchomienie nowego kanału w przyszłym miesiącu lub luki w zgodności z prawem, których nie należy wymyślać od zera. Przykłady operacyjne, które zazwyczaj lepiej kupić: niezawodne eksportowanie dużych plików CSV z zamówieniami, dodawanie kolumny, której oczekują sprzedawcy, lub przyspieszenie działania przepełnionego widoku zamówień. Takie wzorce pojawiają się w poradnikach typu szybsze zarządzanie zamówieniami w WooCommerce – wspólne problemy oznaczają wspólne narzędzia.
Kiedy wygrywa budowanie od zera
Własne rozwiązanie ma sens, gdy dany przepływ pracy jest całkowicie unikalny dla sklepu i żadne gotowe narzędzie nie pokrywa tego przypadku brzegowego bez naginania faktów. Silne sygnały: reguła wynika ze specyfiki działania magazynu, cenników B2B lub synchronizacji z marketplace; dane nie mogą opuścić firmowych serwerów; funkcja daje przewagę konkurencyjną, a nie jest tylko odhaczeniem pola; każda prezentacja aplikacji kończy się stwierdzeniem „musielibyśmy przygotować niestandardowy kod”.
Budowa własnego narzędzia wygrywa również wtedy, gdy zamierza się posiadać dany kod przez lata i można wskazać osobę za niego odpowiedzialną – programistę na etacie, zaufanego partnera z dokumentacją, lub po prostu posiada się wystarczające umiejętności, by samodzielnie dbać o działanie hooków po kolejnej aktualizacji platformy. Jeśli nikt nie odpowiada za aktualizacje, to tak naprawdę nie wybrano budowania. Wybrano przyszłą awarię.
Kiedy zamiast tego poprosić twórcę rozszerzenia
Istnieje jeszcze jedna, często niedoceniana opcja pomiędzy zakupem a budową: wybór najbardziej odpowiedniej, sprawdzonej aplikacji lub modułu, a następnie poproszenie jej twórcy o dodanie drobnej, brakującej funkcji.
Jeśli prośba jest unikalna dla danego sklepu – jednorazowa reguła, z której nikt inny nie skorzysta – twórcy zazwyczaj odmówią i jest to właściwa odpowiedź. Jeśli jednak jest to powszechny problem, na który natrafiają też inni sprzedawcy, a rozszerzenie jest aktywnie rozwijane, często udaje się uzyskać rozwiązanie korzystne dla obu stron: funkcja pojawia się w standardowej aktualizacji, unika się utrzymywania niestandardowego kodu, a produkt twórcy staje się lepszy. W codziennej pracy z modułami i aplikacjami, taka rozmowa rozwiązuje więcej problemów niż tworzenie pełnego, dedykowanego projektu.
Prośba powinna być mała i konkretna (jedna kolumna, jeden filtr, jedno pole eksportu, jedna reguła statusu). Warto wskazać, jak inni mogliby z tego skorzystać. Należy zaakceptować odpowiedź „nie ma tego w planach” bez przekształcania jej w płatne rozwidlenie ich pakietu – to zupełnie inna, bardziej ryzykowna umowa.
Ukryte koszty, które pomijają obie strony
Po stronie kupowania: progi cenowe zależne od liczby stanowisk lub wolumenu zamówień, które gwałtownie rosną po osiągnięciu sukcesu; trzy aplikacje, które nakładają się na siebie i walczą o ten sam status zamówienia; formaty eksportu, które prawie pasują do księgowości; problemy z migracją przy próbie rezygnacji. „Tani abonament miesięczny” staje się drogi, gdy dwa narzędzia wykonują po 60% pracy każde.
Po stronie budowania: aktualizacje platform (hooki w PrestaShop, wersje API w Shopify, wydania WooCommerce), poprawki bezpieczeństwa, dokumentacja oraz tak zwany „bus factor”, gdy tylko jeden freelancer zna repozytorium. Problemy z instalacją i aktualizacją modułów nie są tylko teoretyczne – pojawiają się w najmniej oczekiwanym momencie, dlatego wpisy takie jak problemy z instalacją lub aktualizacją modułu w PrestaShop pozostają aktualne przez lata.
Nie należy mylić „zapytania dostawcy” z drogą kompromisową: zakupem aplikacji pasującej w 80% i płaceniem komuś za skopiowanie lub łatanie pakietu twórcy. Zwykle kosztuje to więcej niż sam zakup gotowego produktu lub wąska budowa własnego rozwiązania, a w dodatku dziedziczy się ryzyko aktualizacji z obu światów.
Jednostronicowa lista kontrolna (oceny 1 – 5)
Należy ocenić każdy wiersz w skali od 1 (faworyzuje kupno, konfigurację lub prośbę do dostawcy) do 5 (faworyzuje budowanie). Wyniki to jedynie wskazówka, a nie wyrok sądu.
- Unikalność problemu: 1 = bardzo powszechna potrzeba na rynku, 5 = specyficzny przepływ pracy w danym sklepie
- Czas do osiągnięcia wartości: 1 = potrzebne w tym tygodniu, 5 = może poczekać miesiąc lub dłużej
- Tempo zmian platformy: 1 = aktualizacje często psują ten obszar (lepiej wybrać utrzymywany produkt zewnętrzny), 5 = na tyle rzadkie, że posiadanie własnego kodu jest realistyczne
- Utrzymanie przez 12 miesięcy: 1 = jasne wsparcie dostawcy, 5 = pełna odpowiedzialność własna lub u jednego freelancera
- Koszt wyjścia: 1 = odinstalowanie i pójście dalej, 5 = skomplikowany, niestandardowy kod do przepisania
- Wrażliwość danych: 1 = bezpieczne w typowym modelu SaaS lub aplikacji, 5 = dane muszą bezwzględnie pozostać na własnych serwerach
Przybliżona ocena: przewaga ocen 1 – 2 → kupno lub konfiguracja gotowego rozwiązania. Przewaga ocen 4 – 5 → budowa wąskiego, własnego rozwiązania. Wymieszany środek → najpierw warto zapytać odpowiedniego dostawcę o dodanie drobnej funkcji; jeśli odmówi lub potrzeba jest naprawdę unikalna, przed zleceniem pełnej wyceny należy wyznaczyć czas na krótki, płatny eksperyment techniczny (maksymalnie dwa dni).
Trzy krótkie scenariusze
1) Dodatkowe kolumny na liście zamówień (data dostawy, numer PO, wiadomość z życzeniami). Zazwyczaj kupno lub konfiguracja. Potrzeba jest powszechna; istnieją już rozwiązania bez użycia kodu oraz aplikacje – w tym bezpłatne wzorce modyfikacji omówione w artykule dostosuj stronę zamówień WooCommerce za darmo bez kodu. Niestandardowy kod PHP dla jednej kolumny rzadko jest wart późniejszych problemów z aktualizacjami. Jeśli solidnemu modułowi brakuje pojedynczej kolumny, warto zapytać jego twórcę, zanim zleci się prywatne modyfikacje.
2) Wyjaśnienie terminologii na stronie sklepu (podpowiedzi, strony ze słowniczkiem). Zazwyczaj kupno, jeśli utrzymywana aplikacja spełnia to zadanie. Budowanie pełnego systemu słownika od podstaw oznacza odtworzenie problemów z wyszukiwaniem, linkowaniem i tłumaczeniem, o które nikt nie prosił – chyba że definicje stanowią kluczowy produkt danej marki.
3) Nietypowa reguła cenowa B2B (grupa klientów × region × data umowy × rodzina SKU). Zazwyczaj budowa (lub mocno skonfigurowany most do systemu ERP). Aplikacje z marketplace zatrzymują się na etapie „prawie gotowe”, a to „prawie” generuje zgłoszenia do pomocy technicznej przy każdym zamówieniu. Oczekiwanie, że generyczna wtyczka cenowa wchłonie specyficzną logikę umów kontraktowych, rzadko bywa realistyczne – to unikalność oceniana na 5.
Jak podjąć decyzję na jednym spotkaniu
Na spotkanie należy przynieść kartę ocen, a nie przeczucia. Trzeba też wskazać osobę odpowiedzialną za każdą z wybranych dróg. W przypadku remisu punktowego, domyślnie należy wybrać kupno przy typowych problemach z administracją, zapytać najlepszego dostawcę w przypadku braku pojedynczej funkcji w aktywnie rozwijanym produkcie, oraz zdecydować się na budowę, gdy mowa o autorskiej logice generowania przychodów – po czym zaplanować dwudniowy, techniczny eksperyment tylko wtedy, gdy te domyślne rozwiązania wciąż wydają się niewłaściwe. Decyzję warto zapisać w jednym akapicie w dokumencie operacyjnym, aby kolejny pracownik nie otwierał tego samego wątku od zera.
Z doświadczenia przy tworzeniu i wdrażaniu modułów oraz aplikacji dla sklepów: niestandardowe rozwiązania, które dobrze zniosły próbę czasu, miały wąski zakres, były udokumentowane i miały przypisanego właściciela. Bolesne projekty zaczynały się jako „tylko drobna poprawka” bez planu aktualizacji. Wiele z tych „brakujących funkcji” wcale nie wymagało budowania na zamówienie – wymagały one jasnej prośby do dostawcy, który już zajmował się danym problemem. Decyzje takie jak kupić czy zbudować aplikację ecommerce należy traktować przede wszystkim jako decyzje o odpowiedzialności za dany element – budżet podąża za tym wyborem.