Kiedy Base.com przestaje się opłacać
Nie wtedy, gdy rośnie abonament. Wtedy, gdy firma zaczyna dopłacać do różnicy między tym, jak platforma każe obsługiwać zamówienia, a tym, jak naprawdę działa sprzedaż.
Base.com, Apilo i podobne platformy rozwiązują prawdziwy problem. Podłączają kanały sprzedaży, zbierają zamówienia, synchronizują stany, drukują etykiety i pozwalają automatyzować powtarzalne kroki. Firma może zacząć sprzedawać wielokanałowo bez finansowania własnego działu produktu.
Dlatego pytanie „czy własny system jest lepszy?” jest źle postawione. Lepsze pytanie brzmi: czy nasz proces nadal mieści się w standardzie, za który płacimy, czy już finansujemy coraz więcej pracy wokół systemu?
Najpierw uczciwie: gotowy system zwykle wygrywa
Na starcie gotowa platforma ma przewagę, której nie da się rozsądnie odtworzyć małym projektem. Base.com deklaruje ponad 2000 integracji, centralne zarządzanie zamówieniami i produktami, automatyzacje wysyłek i fakturowania oraz dostęp do API. Plan Freemium obejmuje do 100 zamówień miesięcznie, a Business dodaje między innymi synchronizację w czasie rzeczywistym, nielimitowaną liczbę produktów i użytkowników oraz 24-miesięczne przechowywanie danych (Base.com, funkcje, cennik).
Konkurencyjne narzędzia pokazują podobną ekonomię. W oficjalnym cenniku Apilo plan Professional kosztuje 399 zł netto miesięcznie do 1500 zamówień, Optimum 799 zł do 5000, a Advanced 999 zł do 10 000. W pakietach są integracje i automatyzacje, choć częstotliwość synchronizacji, liczba użytkowników, retencja danych czy szybsze aktualizacje zależą od planu i dodatków (Apilo, cennik).
Za kilkaset lub kilka tysięcy złotych miesięcznie firma dostaje produkt rozwijany przez duży zespół, dokumentację, infrastrukturę i wsparcie. Własny system nie wygra z tym rachunkiem samą oszczędnością na licencji. Jeśli obsługujesz popularne marketplace’y, masz standardowy magazyn i typową ścieżkę „zamówienie → pakowanie → kurier → faktura”, kupno gotowego narzędzia jest zwykle szybsze, tańsze i bezpieczniejsze.
Cena licencji to tylko jedna linia
Oficjalny cennik pokazuje koszt dostępu do platformy. Nie pokaże kosztu dopasowania firmy do jej modelu danych, obsługi wyjątków ani pracy wykonywanej poza systemem.
Pełny koszt procesu można zapisać prościej niż większość ofert wdrożeniowych:
Miesięczny koszt gotowego systemumodel TCO (total cost of ownership)
To nie jest argument wyłącznie za budową. Własny system również ma koszt utrzymania, hostingu, kopii zapasowych, bezpieczeństwa i zmian w API. Chodzi o porównanie dwóch pełnych rachunków, a nie abonamentu SaaS z jednorazową wyceną programisty.
Thoughtworks zaleca, by model zwrotu obejmował nie tylko licencję, ale też wdrożenie, potrzebną wiedzę, integrację oraz późniejsze wsparcie. Zwraca też uwagę, że elastyczny cennik zmniejsza próg wejścia, ale koszt może rosnąć razem z użyciem, a silne powiązanie z dostawcą podnosi przyszły koszt zmiany („Build versus buy”, s. 29-31).
Pięć sygnałów, że przekroczyłeś granicę
1. Wyjątek stał się codziennym procesem. Operatorzy przepisują identyfikatory, ręcznie poprawiają statusy, przełączają się między panelami albo trzymają „prawdziwą” kolejkę zamówień w arkuszu. Jeżeli obejście ma instrukcję i właściciela, nie jest już wyjątkiem. Jest brakującą funkcją.
2. Jeden status oznacza za mało. Marketplace może osobno opisywać płatność, realizację, wysyłkę i obsługę posprzedażową. Spłaszczenie wszystkiego do jednej kolumny „status” sprawia, że zamówienie opłacone, ale oczekujące na anulowanie, wygląda jak zwykłe zamówienie do wysyłki. Zespół zaczyna pamiętać reguły, których system nie potrafi wyrazić.
3. Firma czeka na cudzą roadmapę. Nowy kanał sprzedaży, niestandardowa umowa z przewoźnikiem albo własny sposób priorytetyzacji ma wartość teraz, ale dostawca musi wybierać funkcje dobre dla tysięcy klientów. To racjonalne po jego stronie. Dla firmy oznacza jednak, że tempo zmiany procesu zależy od zewnętrznej kolejki.
4. Nie wiadomo, co naprawdę się zepsuło. Integracja zwróciła błąd, webhook przyszedł dwa razy, token wygasł albo marketplace dodał nowy status. Jeśli operator widzi jedynie „nie udało się”, a programista nie ma oryginalnego payloadu, historii prób i identyfikatora operacji, diagnoza trwa dłużej niż naprawa.
5. Operacja wpływa na przewagę firmy. Standardowe fakturowanie jest towarem: warto je kupić. Ale własne reguły priorytetów, łączenie kilku modeli logistycznych, terminowość na wymagających marketplace’ach czy specyficzny obieg zwrotów mogą bezpośrednio wpływać na marżę i ocenę konta. Thoughtworks proponuje dokładnie taki podział: funkcje powszechne kupować jako standard, a inwestycję rozważać tam, gdzie sposób działania firmy jest jej wyróżnikiem („Build versus buy”, s. 5-7).
Jak wygląda to w realnym wdrożeniu
W realizowanym przeze mnie projekcie sprzedawca obsługuje pięć kanałów: TikTok Shop, ERLI oraz marketplace’y Empik, Media Expert i Leroy Merlin działające w modelu Mirakl. Z perspektywy operatora to jedna sprzedaż. Z perspektywy API: różne autoryzacje, identyfikatory, statusy, payloady, możliwości wysyłkowe i sposoby ponawiania operacji.
Nie budujemy więc „tańszego Base.com”. Budujemy warstwę operacyjną dla konkretnego sposobu pracy.
Zamówienie · płatność · realizacja · zwrot
Rdzeniem jest kanoniczny model zamówienia. Niezależnie od źródła osobno przechowuje status zamówienia, płatności, realizacji i obsługi posprzedażowej. Oryginalne statusy marketplace pozostają obok, więc nowa wartość z zewnętrznego API nie zatrzymuje synchronizacji i nie znika bez śladu.
Każda integracja jest adapterem: pobiera dane w języku swojego marketplace’u, waliduje je i tłumaczy na wspólny model. Dzięki temu panel zamówień, wysyłka, raporty i automatyzacje nie muszą znać szczegółów TikToka, ERLI czy Mirakl. Dodanie kolejnego kanału nie oznacza przebudowy całego systemu.
Druga ważna rzecz to odporność. Webhook może przyjść ponownie. Odpowiedź API może zawierać nieznany status. Operacja wysyłkowa może zakończyć się timeoutem, choć marketplace zdążył ją wykonać. Dlatego system zapisuje zdarzenia, deduplikuje je, utrzymuje kolejkę z ponowieniami i przed powtórzeniem ryzykownej operacji sprawdza stan po drugiej stronie.
To są niewidoczne elementy dedykowanego systemu, które robią różnicę o 9:00 w poniedziałek. Nie efektowny dashboard, tylko odpowiedź na trzy pytania: co się stało, które zamówienia wymagają działania i czy bezpiecznie można spróbować ponownie?
Gotowa platforma
Firma dopasowuje proces do narzędzia
Integracje, aktualizacje i większość odpowiedzialności operacyjnej bierze dostawca. W zamian firma korzysta z dostępnego modelu procesu i tempa jego rozwoju.
szybki startniski koszt wejścia
Dedykowany OMS
Narzędzie dopasowuje się do firmy
Reguły, dane i kolejność pracy wynikają z operacji firmy. W zamian firma finansuje rozwój, monitoring i utrzymanie własnego produktu.
pełna kontrolawyższy próg wejścia
Nie buduj drugiego Base.com
Najdroższy błąd to próba odtworzenia całej gotowej platformy. Własny system nie musi wystawiać ofert na dwa tysiące integracji, obsługiwać każdego kuriera ani zastępować dobrego programu księgowego. Ma rozwiązać te 10-20 procent procesu, które generuje większość tarcia.
Dlatego w wielu firmach najlepszy jest model hybrydowy:
- marketplace’y pozostają źródłem sprzedaży,
- gotowy system nadal obsługuje funkcje standardowe, które robi dobrze,
- dedykowana warstwa przejmuje wspólny model danych, priorytety i nietypowy workflow,
- integracje są luźno powiązane, aby w przyszłości można było wymienić jeden element bez migracji wszystkiego.
Takie podejście odpowiada również rekomendacji z analizy Thoughtworks: patrzeć na rozwiązanie na poziomie konkretnych zdolności, nie całego pakietu, i ograniczać bezpośrednie zależności od dostawcy przez API (s. 6 i 30).
Policz własny próg
Zanim poprosisz o wycenę, przez dwa tygodnie mierz cztery rzeczy: czas ręcznych poprawek, liczbę zamówień obsługiwanych poza głównym systemem, godziny poświęcone na błędy integracji oraz przypadki, w których ograniczenie narzędzia zatrzymało zmianę procesu. Dopiero te dane tworzą sensowny punkt odniesienia.
Do takiego rachunku trzeba dodać korzyści, których nie da się prosto wycenić: szybsze wejście na nowy kanał, mniej zamówień po terminie, możliwość odtworzenia historii decyzji czy szybszą diagnozę incydentu. Trzeba też dopisać ryzyka budowy: zależność od wykonawcy, koszt dokumentacji, aktualizacje API, bezpieczeństwo danych osobowych i plan awaryjny.
Dobry business case ma trzy scenariusze (ostrożny, realistyczny i ambitny) oraz horyzont co najmniej 24-36 miesięcy. Jeśli inwestycja broni się tylko przy najbardziej optymistycznych założeniach, nie broni się jeszcze.
Werdykt: kupuj standard, buduj przewagę
Gotowy system przestaje się opłacać nie przy 1000, 5000 ani 10 000 zamówień. Wolumen wpływa na rachunek, ale nie wyznacza granicy. Firma z dziesięcioma tysiącami standardowych zamówień może nadal świetnie działać na gotowej platformie. Firma z tysiącem nietypowych zamówień może już tracić więcej na obejściach niż na licencji.
Własny OMS ma sens, gdy jednocześnie:
- kluczowy proces nie mieści się w standardowym modelu,
- różnica ma mierzalny koszt lub wpływa na przewagę firmy,
- zakres da się ograniczyć do konkretnego rdzenia,
- ktoś po stronie biznesu będzie właścicielem procesu,
- budżet obejmuje nie tylko start, ale także utrzymanie i zmiany.
Jeżeli tych warunków nie ma, zostań przy gotowym systemie i lepiej go skonfiguruj. Jeżeli są, nie pytaj, czy da się napisać własny panel. Pytaj, który fragment procesu warto posiadać, a który nadal rozsądniej wynajmować.
Źródła
- Base.com, „Cennik”, dostęp 13 września 2026. Dane o planach, progach, retencji, integracjach i zakresie funkcji.
- Base.com, „Funkcje”, dostęp 13 września 2026. Zakres platformy, deklarowana liczba integracji, API i różnice między planami.
- Base.com, „Rodzaje integracji z platformami marketplace”, dostęp 13 września 2026. Podział integracji na jedno- i dwukierunkowe.
- Apilo, „Cennik Apilo”, dostęp 13 września 2026. Progi zamówień, ceny, użytkownicy, synchronizacja, API i retencja danych.
- Thoughtworks, „Build versus buy: A strategic framework for evaluating third-party solutions”, 2022. Klasyfikacja funkcji, TCO, ryzyko dostawcy i architektura luźnych powiązań.
- Dokumentacja realizowanego wdrożenia OMS, materiał wewnętrzny, wrzesień 2026. Zakres kanałów, model danych, adaptery, obsługa zdarzeń i operacji integracyjnych.