Marketplace nėra katalogas su mokėjimo mygtuku. Tai sandorių ir pasitikėjimo sistema, kurioje skirtingos rolės valdo skirtingus duomenis, pinigai juda keliomis kryptimis, o kiekviena būsena turi nesėkmės kelią. Prieš kuriant ekranus suprojektuoju branduolį, pagal kurį galima pagrįstai vertinti apimtį ir pradėti įgyvendinimą.
Kada marketplace projektas stringa
- Komanda kuria UI, tačiau negali viename lape parodyti viso sandorio gyvenimo ciklo.
- Neaišku, kada autorizuoti mokėjimą, imti komisinį, atlikti išmoką ar grąžinimą.
- Pirkėjo, pardavėjo, organizacijos ir administratoriaus teisės aprašytos tik ekranais.
- KYC, reitingai, moderavimas ir ginčai laikomi priedais, nors jie tiesiogiai lemia pasitikėjimą.
- MVP auga išimtimis, tačiau niekas nevaldo operacinio laiko vienam sandoriui.
Apčiuopiami rezultatai
Marketplace branduolio rezultatai
Sandorio būsenų schema
Pagrindinis sėkmės kelias, atmetimas, laiko pabaiga, atšaukimas, grąžinimas, ginčas ir pakartotiniai webhookai.
Rolių ir teisių matrica
Kas gali matyti, kurti, keisti, tvirtinti ar grąžinti pagal objektą, organizacinį kontekstą ir riziką.
Mokėjimų ir išmokų architektūra
Užsakymas, mokėjimo bandymai, komisiniai, finansinių įvykių žurnalas, išmokos ir suderinimas su tiekėju.
Pasitikėjimo modelis
KYC/KYB slenksčiai, naujo dalyvio limitai, reitingų taisyklės, moderavimo ir apeliacijos kelias.
Operacijų ir išimčių planas
Kiekviena išimtis turi būseną, audito pėdsaką, savininką ir aiškų rankinio darbo automatizavimo slenkstį.
MVP ribos ir įgyvendinimas
Viena geografija, pagrindinė sandorio rūšis, prioritetai, integracijų ribos ir veikiančių etapų planas.
Darbo eiga
Nuo sandorio modelio iki produkto
- 01
Vertės ir pinigų tėkmė
Apibrėžiame, kas kam suteikia vertę, kada atsiranda atsakomybė ir kas kuriuo momentu valdo pinigus.
- 02
Būsenos, rolės ir nesėkmės
Kiekvienam perėjimui priskiriamas iniciatorius, sąlygos, teisės ir nekintamas įvykio įrašas.
- 03
Integracijos ir operacijos
Mokėjimai, KYC, pranešimai, palaikymas, ginčai ir stebėsena tampa viena valdoma sistema.
- 04
Siauras paleidimas
Pirmiausia paleidžiamas mažiausias likvidumą įrodantis branduolys, o ne pusė būsimos ekosistemos.
Aiški atsakomybė
Kas labiausiai keičia apimtį
Sandorio sudėtingumas
Ekranų skaičius nėra pagrindinis kainos veiksnys. Daugiausia lemia rolės, pinigų tėkmė, išimtys, reguliavimas ir integracijos.
Mokėjimų modelis
Tiesioginis apmokėjimas, atidėta išmoka, dalinis grąžinimas, keli gavėjai ir periodinis suderinimas yra skirtingos sistemos.
Mobilus ir web
Vienodas sandoris nereiškia vienodo pristatymo darbo: pranešimai, aplikacijų leidimai ir paskyrų elgsena turi atskiras ribas.
Marketplace įrodymas
Nannow — dviejų pusių paslaugų platforma
6 000+ registracijųMarketplace branduolys, rolės, KYC, Stripe Connect ir mobiliosios aplikacijos; rezultatas pasiektas per keturis mėnesius nuo starto.
Peržiūrėti atvejįFAQ
Dažniausi klausimai
Kiek kainuoja sukurti marketplace platformą?+
Patikimas vertinimas įmanomas tik apibrėžus sandorio būsenas, roles, mokėjimų ir išmokų modelį, KYC, ginčus, mobiliąsias aplikacijas ir integracijas. Todėl pirmas rezultatas yra architektūros ir apimties dokumentas, o ne spėjimas pagal ekranų skaičių.
Ar pradžiai tinka no-code sprendimas?+
Taip, jei sandoris paprastas, pinigai nejuda per platformą ir svarbiausia patikrinti paklausą. Sudėtingos teisės, išmokos, KYC ir individuali rizikos logika no-code ribas atskleidžia greitai.
Kada reikia KYC?+
Ne automatiškai registracijos metu. Patikrą verta aktyvuoti prieš pirmą veiksmą, kuris sukuria reikšmingą riziką — pavyzdžiui, skelbimą, aukštesnį limitą ar pirmą išmoką — pagal konkrečius teisės ir verslo reikalavimus.
Ar kuriate ir mobiliąsias aplikacijas?+
Taip, kai mobilus kanalas yra būtinas sandoriui ar pasiūlos aktyvumui. Pirmiausia vis tiek projektuojamas vienas serverio valdomas sandorio ir teisių modelis.