Tworzenie marketplace'u
Tworzenie marketplace'u dla platform, które startują puste
Dopasowanie, płatności i spory łatwo opisać w specyfikacji, a trudno zrobić dobrze. Przeprowadziliśmy pięć platform przez dzień startu, w którym żadna ze stron jeszcze nie istniała.
- produktów wdrożonych
- 20+produktów wdrożonych
- niszy branżowych
- 4niszy branżowych
- lat budowania
- 4lat budowania
Marketplace to nie katalog z koszykiem.
Wyceniana jest zwykle ta część, którą wszyscy znają: ogłoszenia, wyszukiwarka, płatność. To dobrze opisany problem i nie tam umierają marketplace'y. Umierają w drugim miesiącu, kiedy jedna strona się zarejestrowała, druga nie, a produkt nie daje żadnej z nich powodu, żeby wrócić.
Mechanizmy, które to naprawiają – kto przechodzi weryfikację, co profil musi udowodnić, zanim obca osoba zawrze z nim transakcję, co się dzieje, gdy rezerwacja sypie się w sobotę o 21:00 – trafiają do drugiego etapu. Zanim drugi etap nadejdzie, platforma jest już pusta, a zespół kłóci się o reklamy.
Projektujemy najpierw stan pusty. Pierwsze pytanie nie brzmi, co chcesz zbudować, tylko kto pojawia się pierwszego dnia i dlaczego zostaje, kiedy druga strona jest jeszcze szczątkowa.
Co naprawdę zawiera budowa marketplace'u
Nie lista funkcji. Elementy, które decydują, czy platforma przetrwa pierwszy rok.
Onboarding dwóch stron
Osobne ścieżki dla podaży i popytu, przy czym każda musi być użyteczna, kiedy druga strona jest jeszcze pusta. Ta część projektowana jest zwykle na końcu i waży najwięcej.
Weryfikacja i stany zaufania
Potwierdzanie tożsamości, reputacja, opinie i stany pośrednie – oczekujący, ograniczony, zaufany, zawieszony. W marketplace to nie jest praca zgodnościowa, to jest produkt.
Płatności, wypłaty i zwroty
Escrow albo płatność bezpośrednia, podział środków, zwroty częściowe, harmonogramy wypłat i rozliczanie VAT dla sprzedających z różnych krajów UE. Zwroty są miejscem, w którym większość integracji okazuje się niedokończona.
Dopasowanie i wyszukiwanie
Ranking, który działa przy pięćdziesięciu ogłoszeniach, a nie dopiero przy pięćdziesięciu tysiącach. Geografia, dostępność i trafność dostrojone do ubogiego katalogu.
Spory i moderacja
Kolejki moderacyjne, ścieżki sporów, obsługa dowodów i ręczne nadpisanie każdej automatycznej decyzji. Twój zespół operacyjny potrzebuje wszystkich czterech rzeczy w pierwszym miesiącu.
Narzędzia administracyjne
Wcielanie się w konto użytkownika, zwroty, role i uprawnienia, dziennik zdarzeń. Nigdy nie trafia do portfolio i decyduje o tym, czy platformą da się operować, czy tylko ją pokazywać.
Jak przebiega budowa
Cotygodniowe demo na działającym oprogramowaniu. Bez prezentacji statusowych.
- 01
Audyt zimnego startu
Dziewięćdziesiąt minut o tym, kto dołącza pierwszy i dlaczego zostaje. Czasem uczciwą odpowiedzią jest to, że platforma nie jest ci jeszcze potrzebna – i to powiemy.
Tydzień 0 - 02
Najpierw przepływy, potem piksele
Ścieżki użytkownika, przypadki brzegowe i stany zaufania rozrysowane od początku do końca, razem z tym, jak wygląda każdy ekran bez danych. Tutaj projekty są wygrywane albo przegrywane.
2-3 tygodnie - 03
Budowa w tygodniowych sprintach
Działające środowisko staging od pierwszego sprintu, demo co tydzień. Narzędzia administracyjne powstają razem z funkcją, a nie są obiecywane na później.
8-16 tygodni - 04
Start i pierwsze dziewięćdziesiąt dni
Instrumentacja, procedura moderacji, z której twój zespół faktycznie skorzysta, i zmiany wymuszone przez pierwszych realnych użytkowników. Zostajemy na ten etap.
Na bieżąco
Platformy, które przeprowadziliśmy przez dzień pierwszy
Każda z nich wystartowała bez niczego po obu stronach.
Pachaca
An on-demand cleaning service needed a complete digital ecosystem across mobile, web, and internal operations.
SharingGround
Peer-to-peer item sharing required trust system and logistics
Ski&Sail Club
Build a digital platform for a yacht club that makes trip booking and community management seamless for both newcomers and experienced sailors.
Na czym to budujemy
Nudne, dobrze udokumentowane technologie, które rozpozna twój następny programista.
Produkt
- Next.js
- React
- TypeScript
- React Native
Backend
- Node.js
- NestJS
- PostgreSQL
- MongoDB
- Redis
Operacje
- AWS
- Docker
- CI/CD
- Monitoring
- Operatorzy płatności
Pytania, które dostajemy przed budową marketplace'u
Dwustronne MVP z weryfikacją, płatnościami i działającym panelem administracyjnym to trzy do czterech miesięcy z naszym zespołem. Wycena na sześć tygodni oznacza albo katalog z doklejoną płatnością, albo brak warstwy zaufania – za którą zapłacisz w drugim miesiącu.
Cztery rzeczy, w tej kolejności: ile stanów weryfikacji i zaufania potrzebuje produkt, jak złożony jest przepływ pieniędzy (escrow, podziały, VAT transgraniczny), ile moderacji i obsługi sporów wymaga twoja kategoria oraz ile narzędzi administracyjnych zespół operacyjny potrzebuje na starcie. Zakres i wyłączenia spisujemy przed podpisaniem umowy – zwykle to właśnie tam rozjeżdżają się wyceny.
Często tak. Audytujemy to, co jest, mówimy wprost, które części są w porządku strukturalnie, a które trzeba wymienić, i kiedy łatanie wychodzi taniej niż przepisanie. Robiliśmy jedno i drugie, odradzaliśmy też przepisywanie.
Nie funkcjami. Ustalamy, którą stronę trudniej pozyskać, projektujemy produkt tak, żeby ta strona miała wartość przy pustej drugiej, i dopasowujemy do tego plan startu. Jeśli właściwą odpowiedzią jest etap obsługiwany ręcznie z arkuszem zamiast platformy, powiemy to na pierwszej rozmowie.
Tak. Większość marketplace'ów prędzej czy później potrzebuje przynajmniej jednej aplikacji natywnej, zwykle po stronie podaży. Powiemy też, kiedy responsywna aplikacja webowa kupuje ci kolejne pół roku i aplikacja może poczekać.
Do ciebie, od pierwszego commita. Czysta architektura, testowany kod, udokumentowane systemy, w twoich repozytoriach. Pracujemy na umowach unijnych ze spółki w Poznaniu, więc dane i prawa własności intelektualnej zostają w UE.
Powiedz nam, kto pojawia się pierwszego dnia. Trzydzieści minut, bez sprzedaży. Jeśli marketplace to zły kształt dla tego, co robisz, to też jest użyteczna odpowiedź.
Umów rozmowę