Marketplace fejlesztés: egyedi online piacterek

A funkciók megépíthetők. Ez a könnyebbik fele. A nehezebb az, hogy legyen a platformon egyszerre elég kínálat ahhoz, hogy a vevő találjon valamit, és elég vevő ahhoz, hogy az eladónak megérje ott lennie.

Ezt hívják a piacterek klasszikus tyúk-tojás problémájának: az eladó nem jön, amíg nincs vevő, a vevő nem jön, amíg nincs kínálat. Egy üres piactér senkinek nem vonzó, és aki egyszer üresen találja, ritkán jön vissza.

A szakma erre egy szót használ: likviditás. Ez azt jelenti, hogy mekkora eséllyel jön létre egy tranzakció, ha valaki megérkezik a platformra. A piactér befektetők egybehangzó tapasztalata szerint a legtöbb piactér a likviditás hiányán bukik el, nem a technológián. Az Andreessen Horowitz kockázatitőke-alap megfogalmazásában a likviditás a piactér valódi terméke.

Ezért az induláshoz a legszűkebb rendszert építjük meg, amivel az első valódi tranzakciók létrejönnek, és ezt az alapot úgy tervezzük, hogy a többi funkció rá tudjon épülni.

A legfontosabb induló kérdés a make-or-buy döntés: érdemes-e egyáltalán egyedi platformot építeni, mielőtt a dizájn részleteiről beszélünk. A piacon több dobozos és termékre épülő megoldás is van (Sharetribe, CS-Cart Multi-Vendor, Yo!Kart, Mirakl, vagy nyílt forráskódú alapok, mint a Spree és a Medusa), és őszintén: sokszor ezek a jó opciók.

Egyedi fejlesztőként is azt javasoljuk: ha van a problémádra jól illeszkedő piaci termék, kezdd azzal. Egy olcsó teszt jobb befektetés, mint egy költséges egyedi projekt.

Mikor jönnek elő a dobozos megoldás korlátai?

• Az árazás logikája. A nagyvállalati piactér platformok jellemzően nem csak havidíjat kérnek, hanem a rajtad átfolyó forgalomból, a GMV-ből is részesednek. Ez pont akkor drágul, amikor sikeres vagy.
• A testreszabhatóság. Ha a piacterednek egyedi párosítási logikája, sajátos árazása vagy különleges eladói folyamata van, a dobozos rendszerben ezt vagy nem lehet megcsinálni, vagy elkezdesz egyedi integrációkat építeni köré.
• A függőség és a vendor-lock-in. Ha a teljes üzleted egy szolgáltató keretére épül, a szolgáltató szabályai, díjai és korlátai a te üzleti korlátaid is lesznek.

Az egyedi fejlesztés akkor a logikus válasz, ha a párosítási vagy árazási logika maga a versenyelőnyöd, ha olyan piacon dolgozol, amit az általános platformok nem modelleznek, vagy ha mély integráció kell a meglévő ERP, raktár- vagy háttérrendszerekkel. És van egy köztes út is: a nyílt forráskódú alap vagy az egyszeri licenccel megvásárolható rendszer azt tudja, hogy a kód a tiéd, nincs forgalomarányos platformdíj, mégis gyorsabban indulsz. Logishop termékünk is ebben a logikában működik a webshop oldalon.

A piactér nem semleges felület, hanem közvetítő, ezért olyan szabályok vonatkoznak rá, amik egy sima webshopra nem. Európában az elmúlt években ezek jelentősen szigorodtak, és utólag beépíteni őket lényegesen drágább, mint már a tervezéskor számolni velük.

• Digital Services Act (2022/2065). Az eladók visszakövethetősége: a platformnak be kell szereznie és ellenőriznie az üzleti eladók alapadatait, és be kell kérnie a jogszabályi megfelelési nyilatkozatot.
• Platform-to-business rendelet (2019/1150). Átláthatóság az eladók felé: a rangsorolás fő szempontjait közölni kell, a fizetett kiemelést jelölni kell.
• ÁFA e-kereskedelmi csomag (2021). Bizonyos esetekben a piactér adóügyi szempontból úgy minősül, mintha maga vette és adta volna tovább az árut, és ilyenkor neki kell beszednie és bevallania az áfát.
• GDPR. A kétoldalú adatkezelés miatt a platform és az eladók viszonya többféle lehet (közös adatkezelők, önálló adatkezelők vagy adatkezelő és adatfeldolgozó), ezt esetről esetre kell tisztázni. 
• NAV Online Számla. 2021 óta valós idejű számlaadat-szolgáltatás, a 2025 májusi FA3 sémaváltással bővítve; a hazai piactér számlázási folyamatát ehhez kell illeszteni. 

Ez az a terület, ahol a mérnöki és az üzleti gondolkodás találkozik, és ahol a tanácsadás és specifikáció a projekt elején sok későbbi fejfájást spórol meg. 

A piactér projekt nem a kódolással kezdődik, hanem a feltárással, mert a legtöbb rossz döntés itt előzhető meg. A likviditást biztosító legszűkebb maggal kezdünk, és arra építjük rá a többit.

1. Feltárás és üzleti tisztázás
Melyik online piactér modellről van szó, melyik oldal a nehezebb, hogyan lesz likviditás, milyen jutalék- vagy díjmodell tartja fenn a működést? Ha egy dobozos vagy termékre épülő megoldás is megfelel, ezt már itt jelezzük, mielőtt egyedi fejlesztésbe kezdenénk. 

2. Specifikáció és prototípus
A funkcionális, az integrációs és a vásárlói élmény specifikáció együtt. Egy piactérnél különösen fontos a jogi feltételek és a fizetési folyamat pontos leírása, mert ezek a legdrágábban javítható részek. 

3. Lépésenkénti fejlesztés
A likviditást biztosító modullal kezdünk, utána jön a bővítés. Minden lépés után működő rendszerállapot és visszajelzés. A büdzséd a megkülönböztető logikádra megy, azokra a funkciókra fókuszálva, amelyekben a versenytársaidtól eltérsz, nem azokra, amelyek minden piactérben egyformák. 

4. Élesedés és fokozatos átállás
A fokozatos indulás egyben a likviditás felépítése is: előbb a nehezebb oldal, aztán a könnyebb, előbb a szűk kör, aztán a bővítés.

5. Üzemeltetés és hosszú távú fejlesztés
Az üzemeltetés és a support transzparens SLA-t biztosít; a a bizalomépítést és a fizetési folyamatot folyamatosan karban kell tartani, mert a szabályozás és a csalási minták is változnak. A middleware fejlesztés gyakran kulcsszerepet kap, mert a piactér ritkán él magában, jellemzően ERP-vel, raktárrendszerrel és számlázóval kell kommunikálnia.

❓ Mi az a likviditás egy piactérnél, és miért fontosabb a funkcióknál?
A likviditás azt jelenti, hogy mekkora eséllyel jön létre egy tranzakció, ha valaki megérkezik a platformra. A piactér befektetők egybehangzó tapasztalata, hogy a legtöbb piactér nem a technológián bukik el, hanem azon, hogy sosem éri el vagy nem tudja megtartani a likviditást. Egy szép, de üres piactér senkinek nem vonzó. Ezért a jó marketplace fejlesztés a legszűkebb rendszert építi meg az induláshoz, amivel az első valódi tranzakciók létrejönnek, és a likviditás elindul.

⚔️ Egyedi vagy dobozos platform? Mikor éri meg egyedit építeni?
Ha van a problémádra jól illeszkedő dobozos vagy nyílt forráskódú megoldás (Sharetribe, CS-Cart, Mirakl, Spree, Medusa), gyakran azzal érdemes kezdeni, főleg ha még validálod az ötletet. Az egyedi fejlesztés akkor a logikus válasz, ha a párosítási vagy árazási logika maga a versenyelőnyöd, ha olyan piacon dolgozol, amit az általános platformok nem modelleznek, ha mély integráció kell a meglévő rendszereidhez, vagy ha a forgalomarányos platformdíj már meghaladja egy saját rendszer terhét. Van egy köztes út is: nyílt forráskódú alap vagy egyszeri licenccel megvásárolt rendszer, amit a te piacodra szabunk.

€ Mekkora jutalékot kérjen egy piactér?
A piactér közgazdaságtan régi tanulsága szerint az egészséges take-rate jellemzően tíz és tizenöt százalék körül van. A harminc százalék fölötti jutalék veszélyes: pont annyira fáj az eladóknak, hogy elkezdik megkerülni a platformot, vagy versenytársat vonzanak be. A leggyakoribb kezdő hiba, hogy a piactér túl sokat akar elvenni. A jó szabály, hogy annyit vegyél el, amennyi a fenntartható működéshez épp elég, különben a saját kínálatodat űzöd el. A jutalék mellett más modellek is keverednek: előfizetés, listázási díj, lead díj, prémium megjelenés.

⚙️ Kell-e saját fizetési rendszert építeni a piactérhez?
Szinte soha nem éri meg. A kártyatársasági regisztráció, a régiónkénti engedélyek és a pénzmosás-ellenőrzés terhe akkora, hogy a legtöbb egyedi piactér is egy engedélyezett fizetési szolgáltatóra ül rá (Stripe Connect, Adyen, Mangopay). A megosztott fizetés lényege, hogy egyetlen vásárlói fizetés automatikusan szétoszlik az eladó és a platform között úgy, hogy a pénz nem a platform számláján áll meg. Így a platform nem lesz szabályozott intézmény. Az egyediség a platform logikájában van, nem a fizetés újrafeltalálásában.

▶️ Melyik oldalt hozzuk be előbb, az eladókat vagy a vevőket?
Jellemzően a nehezebb oldalt, ami legtöbbször a kínálati, vagyis az eladói oldal. Ha megvan elég eladó és elég kínálat, a keresleti oldalt sokkal könnyebb megszólítani. Két további bevált minta: szűken kezdj (egyetlen város, termékkör vagy szakma hamar megtelik, egy országos piactér első nap ijesztően üres), és adj értéket, mielőtt a hálózat létrejönne (sok piactér úgy indult, hogy először egy hasznos önálló eszköz volt az egyik oldalnak, és csak amikor az eladók már ott voltak, kapcsolt rá a piactér funkció).

⚖️ Milyen jogi szabályok vonatkoznak egy piactérre Magyarországon?
A piactér közvetítő, ezért szigorúbb szabályok vonatkoznak rá, mint egy sima webshopra. A legfontosabbak: a Digital Services Act (eladók visszakövethetősége), a platform-to-business rendelet (átláthatóság az eladók felé), a 2021-es uniós ÁFA e-kereskedelmi csomag (a piactér bizonyos esetekben adóbeszedő), a GDPR (többféle lehetőséget rejtő, kétoldalú adatkezelés) és Magyarországon a NAV Online Számla valós idejű adatszolgáltatása (a 2025 májusi FA3 sémaváltással). Ezeket érdemes már a tervezéskor beépíteni, mert utólag lényegesen drágább.

⚡ Mennyi ideig tart egy marketplace fejlesztés?
A komplexitástól függ, de az elv mindig ugyanaz: nem a teljes platformot építjük meg elsőre. A feltárás és a specifikáció után a likviditást biztosító legszűkebb maggal kezdünk, amivel valódi tranzakciók jöhetnek létre, és arra építjük rá fokozatosan a többit. Ez lényegesen gyorsabb élesedést ad, mint egy hónapokig csendben csiszolt, mindent tudó platform, amiből a launch napján derül ki, hogy nincs rajta forgalom. A pontos scope-ot és ütemtervet a feltárási szakasz után, indikatív ajánlatban rögzítjük.

⚙️ Milyen technológiai stacken dolgozunk?
A piactér természeténél fogva több szereplős rendszer, ahol a részek (eladó regisztráció, termékadat, kereső, rendelés szétosztás, fizetés megosztás, készlet) más ütemben terhelődnek, ezért a szolgáltatás alapú felépítés felé húz. A keresőnél Algolia, Elasticsearch, Meilisearch vagy Typesense; a fizetésnél Stripe Connect, Adyen vagy Mangopay; a keret lehet egyedi, nyílt forráskódú alap (Spree, Medusa) vagy termékre épülő. A legkényesebb technikai probléma jellemzően a valós idejű készlet, amit vegyesen kezelünk: a gyorsan fogyó termékeknél szigorú zárolás, a lassabbaknál puffer és eseményvezérelt frissítés. A middleware fejlesztés itt gyakran kulcsszerepet kap az ERP, raktár- és számlázórendszerekkel való kommunikációhoz.

♣️ Mi a franchise piactér, és miért más, mint egy sima piactér?
A franchise piactér akkor jön szóba, amikor több önálló partner ugyanazt a márkát viszi. A hagyományos piactér modell itt rossz, mert ha minden partner ugyanazt a terméket árulja, a vevő az ár alapján választ, és lefelé húzó árverseny indul. A jól működő minta a Wolt logika: a vevő először kiválaszt egy partnert (jellemzően a helymeghatározás alapján a legközelebbit), és onnantól úgy vásárol, mint egy sima webshopban. A márka egységes, a partnerek nem versenyeznek egymással, és mégis megtartják az önállóságukat. Ehhez egy intelligens partnerválasztó kell (helymeghatározás, szállítási zónák, készlet elérhetőség), amit a dobozos webshop platformok natívan nem támogatnak.

Írd le, milyen piacot szeretnél kiszolgálni, kik lennének az eladók és a vásárlók, és hogyan működne az üzleti modelled. Segítünk felmérni, hogy kész platform vagy egyedi fejlesztés éri-e meg, és hogyan érdemes elindítani a piacteredet.