Rozdziały przewodnika
Jak korzystać z tego przewodnika
Ten przewodnik odpowiada na jedno pytanie: jak zbudować najmniejszy marketplace, który działa poprawnie dziś, nie podejmując po drodze kilku decyzji, które za rok wymuszą przepisanie połowy systemu.
Dla kogo#
Dla założyciela, product ownera albo dewelopera, który planuje MVP, mały albo średni marketplace możliwy do zbudowania i utrzymania przez jedną osobę lub kilkuosobowy zespół. Zakładany rząd wielkości to kilkudziesięciu sprzedawców i kilka tysięcy produktów, a nie miliony ofert i własna sieć magazynów.
Marketplace w tym przewodniku może być samodzielną platformą z własnym katalogiem i checkoutem, rozszerzeniem istniejącego sklepu o sprzedawców zewnętrznych albo platformą, na której sprzedawcy prowadzą już własne sklepy i chcą podpiąć katalog lub stany.
Czego tu nie ma#
Nie ma tu też architektury pisanej pod skalę, której nie masz. Rozwiązania rozproszone, własne przetwarzanie płatności, rozbudowane systemy antyfraudowe i wielomagazynowa logistyka pojawiają się tylko po to, żeby wyjaśnić, dlaczego są poza zakresem albo jaki konkretny wyzwalacz kazałby o nich pomyśleć.
Struktura rozdziału#
Każdy rozdział trzyma tę samą kolejność, żeby dało się go czytać wybiórczo:
- problem w kategoriach biznesowych, nie technologicznych;
- minimalna wersja, czyli najmniejsza implementacja, która jest poprawna i da się na niej operować;
- czego nie budować na tym etapie;
- co zaplanować z góry, bo później jest drogie;
- wyzwalacze, po których obecna wersja przestaje wystarczać;
- następny etap, zawsze przyrostowy;
- częste błędy i checklista.
Słownik#
Te pojęcia wracają w każdym rozdziale i znaczą dokładnie to, co poniżej.
| Pojęcie | Znaczenie |
|---|---|
| Minimalna wersja | Najmniejsza implementacja, która jest poprawna i pozwala prowadzić działalność. Nie prototyp. |
| Zaplanuj z góry | Decyzja o strukturze danych, która dziś kosztuje kilka godzin, a pominięta kosztuje migrację. |
| Wyzwalacz | Konkretne zdarzenie operacyjne, po którym trzeba rozbudować moduł. Nie "gdy urośniemy". |
| Następny etap | Kolejna sensowna implementacja po wyzwalaczu, nie wersja docelowa. |
| U dostawcy | Odpowiedzialność oddana usłudze zewnętrznej, wraz z granicą tej odpowiedzialności. |
| Ręcznie | Proces świadomie wykonywany przez człowieka, adekwatny do obecnej skali. |
| Zaawansowane | Implementacja spoza domyślnego zakresu tego przewodnika. Nie znaczy "lepsza". |
Jak oceniam rekomendacje#
Zanim w tym przewodniku pojawi się rekomendacja zbudowania czegokolwiek, przechodzi przez siedem pytań:
- Czy marketplace potrzebuje tego, żeby działać poprawnie już teraz?
- Czy to jest potrzebne głównie przy większej skali?
- Czy dostawca zewnętrzny może przejąć tę odpowiedzialność?
- Czy proces może na początku zostać ręczny?
- Czy pominięcie tego dziś oznacza kosztowną migrację później?
- Czy da się zachować drogę rozwoju małą decyzją o modelu danych, zamiast budować całą funkcję?
- Czy rekomendacja wynika z doświadczenia albo z jasno wyjaśnionej zasady, a nie z przyzwyczajenia?
Relacja do przewodnika regulacyjnego#
Ten przewodnik nie powtarza obowiązków prawnych. Tam, gdzie temat dotyka wymogów rynku UE, mówi wyłącznie o tym, co z nich wynika dla modelu danych i przepływu, i odsyła do drugiej ścieżki dostępnej z tej samej strony.
Podział jest prosty: obowiązki operatora odpowiadają na pytanie "co muszę spełnić", ten przewodnik na pytanie "jak to zamodelować, żeby dało się to spełniać bez przepisywania systemu".
Projektuję platformy multi-vendor wraz z onboardingiem, płatnościami, moderacją i procesami operacyjnymi.
Zobacz usługę budowy marketplace