Endora Commerce od środka – dlaczego zdecydowałem się zbudować własną platformę B2B

Przez ponad dekadę wdrażaliśmy platformy e-commerce dla innych firm. Magento, Shopware, Sylius — znamy te systemy bardzo dobrze, ze wszystkimi ich mocnymi stronami i ograniczeniami. W pewnym momencie doszedłem do wniosku, że najuczciwszą rzeczą, jaką możemy zrobić dla potencjalnych klientów, jest pokazanie działającego systemu zamiast kolejnego zestawu slajdów. To nie był projekt „zróbmy własny produkt”. To był projekt „przestańmy opowiadać, a zacznijmy pokazywać”.

---

Punkt, w którym postanowiłem coś zmienić

Pamiętam konkretne spotkanie. Klient z branży dystrybucji przemysłowej, poważna firma, cztery godziny warsztatów. Wiedzieliśmy co zbudować: silnik cenowy, RFQ, panel zarządzania wieloma magazynami, integracja z ERP. Mieliśmy dobre referencje, rzetelną wycenę, przemyślaną roadmapę.

Na koniec padło pytanie: czy możemy to gdzieś zobaczyć? Coś, co naprawdę działa?

Pokazałem screenshoty z poprzednich wdrożeń. Film demo z YouTube. Opis architektury.

I widziałem, że to nie wystarczy. Nie dlatego, że klient nam nie ufał. Ale nie umiał na podstawie tych materiałów wyobrazić sobie, jak jego handlowcy będą składać zamówienia, jak administrator zmieni cennik, jak kupujący zobaczy swoje indywidualne ceny. To spotkanie nie skończyło się kontraktem. Skończyło się miesiącem korespondencji, dodatkowym warsztatem i projektem z inną agencją.

Przez kolejny rok dostawałem to samo pytanie w różnych wersjach. I za każdym razem odpowiadałem tym samym: obietnicami i referencjami.

W pewnym momencie powiedziałem sobie: dość.

---

Dlaczego nie Magento ani Shopware

Kiedy zdecydowałem, że budujemy własną platformę — prawdziwą, nie prototyp do prezentacji — pierwsza decyzja była zaskakująco szybka: nie budujemy na Magento ani Shopware.

Nie dlatego, że to złe platformy. Wdrożyliśmy ich dziesiątki. Ale każda z nich niesie kilkanaście lat decyzji architektonicznych, nie wszystkich trafnych. Wtyczki, konfiguracje, cache, indeksery. Zanim napiszesz pierwszą linię kodu biznesowego, przez trzy dni konfigurujesz środowisko.

Chciałem, żeby demo było żywe. Żeby zmiana ustawienia w panelu administratora była widoczna natychmiast na storefront. Żeby ścieżka „zmień cennik dla grupy klientów, przejdź na storefront, cena inna” trwała dwie sekundy, nie trzydzieści.

Zdecydowałem na Next.js po stronie frontendu i architekturę API-first po stronie backendu. Zero gotowych rozwiązań tam, gdzie chcemy mieć pełną kontrolę. Gotowe biblioteki tam, gdzie kontrola nie jest kluczowa.

To była dobra decyzja i jedna z nielicznych, w której nie miałem wątpliwości od początku.

---

Jak to zbudowaliśmy

Spec-Driven Development — metodologia, którą stosujemy w projektach klienckich — zaczyna się od specyfikacji. Zanim napiszesz kod, piszesz wymagania funkcjonalne: co system robi, jak się zachowuje w edge case’ach, co jest sukcesem testu.

Wydawało mi się, że dla własnego produktu to będzie łatwiejsze. Znam branżę, znam potrzeby klientów B2B, sam wiem czego chcę.

Myliłem się.

Bycie jednocześnie klientem i zespołem projektowym to dziwne doświadczenie. Nie ma kogoś, kto pyta „a dlaczego tak?”. Nie ma zewnętrznej presji wymuszającej priorytety. Wszystko wydaje się jednakowo ważne.

Pierwsza wersja specyfikacji modułu cenowego miała piętnaście stron i obejmowała każdy możliwy edge case. Była doskonała i całkowicie bezużyteczna jako punkt startowy — bo nie wiedziałem co muszę zbudować w tym tygodniu, żeby mieć cokolwiek do pokazania. Nauczka: im lepiej znasz domenę, tym trudniej wybrać minimum.

Dałem sobie konkretne ograniczenie: MVP musi działać jako demo dla dystrybutora przemysłowego. Jeden scenariusz, jeden typ użytkownika, jeden typ produktów. Reszta na później. To odblokowało pracę.

---

AI jako pair programmer

Nie piszę o Endora Commerce jako „projekcie AI-assisted” dlatego, że to modne słowo. Piszę tak, bo bez AI ten projekt zabrałby dwa razy więcej czasu.

Pracowałem z Claude’m jako pair programmerem. Pisałem specyfikację modułu w języku naturalnym, Claude pisał testy jednostkowe i integracyjne, potem implementację względem tych testów. Mój udział to code review i korekta logiki biznesowej tam, gdzie AI popełniało błędy w rozumieniu domeny.

To jest inne doświadczenie niż „poproszę o kod”. AI, które widzi pełny kontekst specyfikacji, pisze sensownie. AI, które dostaje samotne „napisz mi moduł cenowy”, pisze coś, co wygląda jak moduł cenowy, ale zachowuje się jak losowy generator pomysłów.

Spec-Driven Development i AI to naturalna para: AI jest tak dobre, jak dobre jest pytanie, które mu zadajesz. Dobra specyfikacja to dobre pytanie.

Jedną z funkcji platformy jest asystent AI sterowany językiem naturalnym — otwierasz paletę poleceń ⌘K, wpisujesz po polsku „przypisz produkt X do kategorii Y i ustaw cenę 450 zł dla grupy klientów hurtowych”, system pokazuje plan i czeka na potwierdzenie. Zbudowałem tę funkcję żeby mieć ją w produkcie, ale też dlatego, że sam chciałem z niej korzystać podczas budowania. Dog fooding w czasie rzeczywistym.

---

Moment, gdy to zadziałało

Pod koniec czwartego tygodnia zalogowałem się na storefront jako buyer@demo-org.example. Zobaczyłem katalog z cenami. Dodałem produkty do koszyka. Złożyłem zamówienie przez RFQ.

Potem zalogowałem się do panelu admina. Zobaczyłem zamówienie. Zmieniłem status.

Wróciłem na storefront. Status był zaktualizowany.

To brzmi banalnie. Ale po tygodniach budowania moduł po module, w których każdy działał osobno, zobaczenie ich razem jako spójny przepływ jest czymś innym. Zrobiłem screenshota i wysłałem do trzech osób. „Działa.”

---

Być swoim pierwszym klientem

Endora Commerce obsługuje nasze wewnętrzne procesy: konfigurację demo dla prospektów, zarządzanie środowiskami, historię zmian. I to jest najbardziej wartościowa część całego projektu. Nie żaden feature, nie architektura, nie AI.

Kiedy używasz systemu, którego jesteś autorem, odkrywasz rzeczy niewidoczne podczas budowania.

Przykład: asystent AI w panelu jest doskonały, gdy wiesz dokładnie czego chcesz. Gdy chcesz „jakoś” zmodyfikować produkt, nie wiesz jak sformułować polecenie, żeby dostać to, co masz w głowie. To nie jest bug w oprogramowaniu. To informacja: wdrożenie asystenta AI wymaga czasu na naukę jak z nim rozmawiać. Klientom trzeba to powiedzieć.

Gdybym dowiedział się tego od klienta po wdrożeniu, byłby to red flag w retrospektywie. Dowiedziałem się sam, zanim to pojechało do kogokolwiek. Naprawiłem onboarding.

Dlatego warto być pierwszym klientem własnego produktu. Nie dlatego, że „tak mówi każdy startup guru”. Dlatego, że bóle, które sam czujesz, naprawiasz w godzinę. Bóle, które odczuwa twój klient, naprawiasz po tygodniu na zgłoszenie i tygodniu na wdrożenie.

---

Co mnie zaskoczyło

Spodziewałem się, że cztery tygodnie do MVP będą agresywnym targetem. Okazały się możliwe. AI skróciło czas implementacji na modułach dobrze zspecyfikowanych o 30–40%. To wystarczyło, żeby zmieścić się w oknie.

Spodziewałem się, że silnik cenowy będzie najtrudniejszą częścią. Okazał się jednym z szybszych modułów, bo wymagania były precyzyjne i logika biznesowa, choć złożona, była dobrze opisana. Najtrudniejszy był moduł kanałów sprzedaży — dlatego, że „co to znaczy” różniło się za każdym razem, gdy o nim myślałem.

Najtrudniejsze okazało się bycie jednocześnie klientem i agencją. Przy projekcie klienta jest zewnętrzna presja, deadlines, ktoś kto mówi „za trzy tygodnie muszę pokazać zarządowi”. Przy własnym projekcie tę presję musisz sam sobie stworzyć. To jest trudniejsze, niż myślałem.

I był jeszcze ten moment, gdy demo trafiło na pierwsze spotkanie sprzedażowe. Klient spojrzał, usiadł przy laptopie i przez dwadzieścia minut testował bez pytań do mnie, bez proszenia o wyjaśnienia. Po prostu sprawdzał. To było inne niż wszystkie poprzednie spotkania.

---

Gdzie to jest teraz

Endora Commerce jest dostępna — nie jako SaaS do zainstalowania z paczki, ale jako platforma, którą budujemy razem z klientem na jej architekturze i modułach, dostosowaną do konkretnej branży i procesów.

Działające demo jest dostępne bez rejestracji i bez rozmowy ze sprzedawcą jako warunek wstępny:

Demo storefront → — zaloguj się jako buyer@demo-org.example / ChangeMe!123 i przejdź przez ścieżkę zakupową B2B

Demo admin panel → — zaloguj się jako admin@demo.local / ChangeMe!123 i sprawdź jak wygląda zarządzanie platformą od środka

Jeśli interesuje cię cały proces od strony agencyjnej — jak demo skraca cykl sprzedażowy B2B, jak wygląda warsztat → prototyp → decyzja — opisałem to szczegółowo w case study Endora Commerce.

---

Jedna rzecz na koniec

Nie zbudowałem Endora Commerce żeby ją sprzedawać. Zbudowałem ją żeby mieć coś prawdziwego do pokazania.

Paradoksalnie sprawia to, że jest lepsza niż gdybym budował ją z myślą o sprzedaży. Buduję ją z myślą o użytkowaniu. I to jest, jak odkryłem przez te miesiące, jedyna miara, która ma sens przy budowaniu czegokolwiek.

Klient, który sam przetestuje demo zanim cokolwiek podpisze, rozumie co kupuje. Nie wyobraża sobie. Wie.

To zmienia dynamikę rozmowy sprzedażowej — z „ufaj nam” na „sprawdź sam”. I przez kilka lat było jedyne czego mi brakowało.

---

Endora specjalizuje się w platformach e-commerce B2B — zarówno wdrożeniach na Magento, Shopware i Sylius, jak i dedykowanych rozwiązaniach takich jak Endora Commerce. Jeśli zastanawiasz się nad platformą B2B dla swojej firmy — umów bezpłatną konsultację.