Európai Uniós Pályázat Lioner Weboldalak

JustConnect

Weboldal Webalkalmazás
Szántó Dávid
2026
JustConnect desktop
JustConnect mobil

A projektről

Eseményalapú kapcsolódási platform a nulláról, százfős offline események lebonyolítására. A résztvevő a jegyvásárlás után meghívót kap, létrehozza a fiókját és kitölti a profilját, a helyszínen QR-rel jelentkezik be, és a telefonján követheti, melyik körben hova ül vagy kivel beszélget – a beosztást a szervező hagyja jóvá és nyitja meg körönként, élőben. Az esemény után kölcsönös szimpátia esetén jön létre az egyezés és a kapcsolatfelvétel. Mellette teljes szervezői admin, exportok, két nyelv, jegyértékesítő- és hírlevél-integráció, valamint saját CMS a publikus oldalhoz. Laravel alapon, mobilra tervezve.

Az ügyfél véleménye

Nagyon pozitív tapasztalatunk volt a Lioner csapatával. Weboldal és adminfelület fejlesztésében dolgoztunk együtt, és több összetettebb, egyedi fejlesztési feladatot is sikeresen megoldottak.

Szakmailag felkészültek, precízek és rugalmasak, a közös munka során pedig mindig lehetett rájuk számítani. Külön értékeltük, hogy a bonyolultabb igényekre is jól működő megoldásokat találtak.

Egyedi fejlesztésű eseményplatform: így épült a Just Connect rendszere

Százfős offline események teljes digitális lebonyolítása: jegytől a profilig, QR check-intől az élőben megnyitott körökig, az esemény utáni kapcsolatfelvételig. A szervezőnek admin, a résztvevőnek egy telefon.

A Just Connect budapesti közösségi és szingli események szervezője: társas estek, túrák, piknikek, rapid randi és profil alapú ismerkedős alkalmak. A feladatunk nem egy bemutatkozó oldal volt, hanem az a rendszer, ami magát az eseményt viszi végig – attól a pillanattól, hogy valaki megveszi a jegyét, addig, amíg az esemény után felveszi a kapcsolatot azzal, akivel jól elbeszélgetett.

Ennek a rendszernek van egy sajátossága, ami minden döntést meghatározott: nem az irodában fut, hanem a helyszínen, élesben, száz ember telefonján egyszerre. Ha egy kör beosztása nem jelenik meg időben, azt nem egy hibajegy jelzi, hanem száz ember áll tanácstalanul a teremben. Ez az oldal arról szól, mit jelent ez a gyakorlatban.

A feladat: az esemény nem a weboldalon történik

Egy százfős ismerkedős esten a szervezőnek több kört kell levezényelnie: ki hova ül, kivel beszélget, mikor váltanak. Ezt papíron megoldani nem lehet, mert a létszám az utolsó pillanatig változik – valaki nem jön el, valaki később érkezik, valaki bejelentkezik, de nem tölti ki az adatlapját.

A rendszer ezért nem egy statikus beosztást készít, hanem végigkíséri az esemény teljes életútját: regisztráció, profil, check-in, körök, szavazás, egyezés. Minden lépés ugyanazokra az adatokra épül, és minden lépésnél az a kérdés vezetett, hogy mi történik, ha valami nem a terv szerint alakul.

A belépés útja: a jegytől a kitöltött profilig

A résztvevő a jegyét külső jegyértékesítőn veszi meg. Innen a rendszer veszi át: meghívó levelet küld, amiben egy saját linkről indul a regisztráció, és onnantól minden a fiókjához tartozik – a profilja, az eseményei és a beosztásai.

A regisztráció e-mail címmel és jelszóval történik, de szándékosan a lehető legkevesebb lépésből. Aki a helyszínen, QR kóddal találkozik először a rendszerrel és még nincs fiókja, az egy kiküldött linket kap, amin már csak a jelszót kell beállítania – a címét a rendszer már ismeri. A regisztrációs és jelszó-visszaállító űrlapok robotvédelem és kérésszám-korlát mögött vannak.

A profil kitöltése ezután két részre bomlik: az alapadatokra, amiket egyszer ad meg, és az adott eseményhez tartozó rövid hangulatkérdésekre, amiket az esemény előtt tölt ki. Ez utóbbi nem formaság – aki tavaly februárban töltötte ki, hogy épp mire vágyik, az ma valószínűleg mást válaszolna. A szétválasztásnak gyakorlati oka van: egy hosszú, mindent egyszerre bekérő űrlap a leggyorsabb módja annak, hogy valaki félbehagyja a folyamatot.

A helyszínen: QR check-in és egy kézzel használható felület

Az esemény napján a résztvevő a saját QR kódját mutatja, a szervező pedig telefonnal olvassa be – vagy kézzel jelöli be, ha valakinél épp lemerült a telefon. A check-in nem adminisztráció: ebből tudja a rendszer, hogy ki van ténylegesen a teremben, és a beosztás csak velük számol.

A résztvevői felület mobilra készült, nem mobilra is: nagy érintőfelületek, alul elérhető navigáció, képernyőnként kevés döntés. A tervezési alap az volt, hogy valaki egy kézzel, félhomályban, zajban, poharat fogva használja.

A beosztás: a rendszer javasol, a szervező dönt

A körök beosztását saját fejlesztésű motor készíti a résztvevők profil- és hangulatválaszai alapján. A működésének részletei az ügyfél üzleti tudása, ezért itt nem részletezzük – amiről viszont érdemes beszélni, az a körülötte lévő munkafolyamat, mert a gyakorlatban ez dönti el, használható-e egy ilyen rendszer.

  • A generált beosztás először piszkozat. A szervező látja, hány résztvevő került be, ki maradt ki és miért, és csak akkor teszi élővé, ha rendben találta. Semmi nem kerül a résztvevők elé jóváhagyás nélkül.
  • A körök egyesével nyithatók. Nem egyszerre kap mindenki mindent: a szervező akkor nyitja a következő kört, amikor az előző valóban véget ért.
  • Az eredmény felülbírálható. Egy résztvevő kézzel áthelyezhető, és a hátralévő körök újragenerálhatók. A gép javaslata nem szentírás – a szervező látja a termet, a rendszer nem.
  • A későn érkező beilleszthető. Aki a kezdés után jön meg, bekerül a következő körökbe anélkül, hogy az egészet újra kellene osztani. Élő eseményen ez nem ritka kivétel, hanem minden alkalommal előfordul.

Élő körök: ami a telefonon magától megjelenik

Amikor a szervező megnyit egy kört, a résztvevők telefonján azonnal megjelenik a helyük – nem kell frissíteni, nem kell újratölteni, nem kell megkérdezni senkitől. Ezt állandó kapcsolat adja a szerverrel, nem ismételt lekérdezés.

Itt ez nem technikai fényűzés. Egy teremben, ahol száz ember egyszerre keresi a következő asztalát, a néhány másodperces csúszás is zavart okoz, a „nálam még nem jött be” pedig azonnal a szervezőhöz küldi az embereket. Ugyanígy megy ki a többi időérzékeny esemény is: a kör lezárása és az esemény utáni értesítések.

A beosztás mellett a résztvevő beszélgetésindító kérdéseket és a társaságával közös érdeklődési köreit is látja. Ez a rendszer legolcsóbb és leghasznosabb eleme: az első néhány percen segít át, ami egyedül érkezőnek a legnehezebb.

Az esemény után: szimpátia, egyezés, kapcsolatfelvétel

Az esemény alatt és után a résztvevők jelezhetik, kivel szeretnének kapcsolatban maradni. Elérhetőség csak kölcsönös jelzésnél kerül át, eseménytípustól függő szabályok szerint, bizonyos esetekben külön megerősítéssel. A pontos szabályrendszer szintén a megrendelő üzleti döntése.

Az elv viszont elmondható, és minden ilyen rendszerre igaz: az egyoldalú érdeklődésből soha nem lesz elérhetőség. Aki nem jelzett vissza, arról a másik fél nem tud meg semmit – még azt sem, hogy megkeresték. Enélkül egy ismerkedős esemény a résztvevők egy részének kellemetlen élmény lenne, és többé nem jönnének el.

A résztvevők a körökről visszajelzést is adhatnak, a szavazás pedig elhalasztható, ha valaki épp beszélgetés közben van – nem akartuk, hogy a telefon szólítsa el az embereket attól, amiért kijöttek.

Amit a szervező kapott

A szervezői felület az esemény teljes életciklusát kezeli: eseménysablonok és események létrehozása, másolása, közzététele és lezárása; kérdéskészletek és beszélgetésindító kérdések összeállítása; résztvevőkezelés, ahol egy listában látszik, kinek hiányzik a profilja, a hangulatválasza vagy a check-inje.

Emellett kilenc különböző export (résztvevők, beosztások, párosítások, szavazatok, visszajelzések, statisztikák), teljes műveletnapló, és egy megszemélyesítés funkció, amivel a szervező a saját szemével látja, mit lát egy adott résztvevő – ez hibakeresésnél többet ér minden képernyőképnél.

Személyes adatok: a törlés valóban törlés

Egy ismerkedős platform érzékeny adatokkal dolgozik, ezért a fiók törlése nem elrejtés. A rendszer anonimizál: a profiladatok, a fénykép és minden személyhez köthető mező eltűnik, a hírlevél-szolgáltatótól is töröljük a címet, viszont az esemény statisztikái nem sérülnek. A törölt e-mail cím ettől újra használhatóvá válik, ha valaki később mégis visszatérne.

A beszélgetések és szavazatok csak a saját eseményük résztvevőinek érhetők el, a publikus űrlapok pedig robotvédelem és kérésszám-korlát mögött vannak.

A publikus oldal és a nyelvek

A nyilvános oldal ugyanabban a rendszerben él: blokk-alapú oldalszerkesztő, médiatár, menükezelő, eseménykatalógus, valamint értesítéskérés azokra a formátumokra, amikre épp nincs meghirdetett időpont – ebből lesz a következő esemény közönsége. A feliratkozók a hírlevélrendszerbe is átszinkronizálódnak, a leiratkozás és a törlés pedig mindkét helyen érvényesül.

A résztvevői felület magyarul és angolul is használható, mert a nemzetközi eseményeken nem mindenki beszél magyarul. A hasonló rendszereket ugyanezen az alapon építjük, akkor is, ha csak weboldal készítésről van szó, és akkor is, ha összetett üzleti rendszerről.

Technológia

Laravel alapokon, saját adminnal és CMS-sel, valós idejű kapcsolattal a résztvevői felület felé, külső jegyértékesítő- és hírlevél-integrációval. A fejlesztés lépésekre bontva, dokumentált munkaverziókban haladt, mert egy ilyen rendszernél nem az első éles eseményen szabad kiderülnie, hogy valami nem működik – ott már száz ember áll a teremben.

Mit vigyen el ebből, aki eseményplatformot tervez

Három dolog dönti el egy ilyen rendszer sorsát. Az első, hogy mennyi súrlódás van az útban: minden felesleges lépés – újra bekért adat, hosszú űrlap, homályos következő lépés – résztvevőket veszít, méghozzá pont azokat, akik amúgy is bizonytalanok. A második, hogy mennyire bírja a váratlan helyzetet: a késői érkezőt, a kimaradó adatot, a kézi átmozgatást. A harmadik, hogy a szervező kezében marad-e a döntés – mert egy élő eseményen mindig lesz olyan helyzet, amit csak ember lát.

Nézze meg a többi referencia munkánkat is, vagy ha van egy konkrét ötlete, vegye fel velünk a kapcsolatot. Az első konzultáció ingyenes, és a végén akkor is okosabb lesz, ha nem velünk dolgozik tovább.

Gyakori kérdések az eseményplatform fejlesztésről

Amit a rendezvényt kiszolgáló, élesben működő rendszerek előtt a leggyakrabban kérdeznek tőlünk.

Több hónap, és lépésekre bontva érdemes haladni vele. Egy ilyen rendszernél ugyanis nem elég, hogy a fő forgatókönyv működik: a munka java a kivételek kezelése – aki késik, aki nem töltött ki valamit, aki bejelentkezett, de nem jött el. Pontos ütemezést az első konzultáció után tudunk mondani, amikor már látjuk a tényleges funkciólistát.

Erre nincs listaár, mert a különbség nem a megjelenésben van, hanem abban, hány funkció kerül bele. A regisztráció, a helyszíni check-in, az esemény alatti vezérlés és az esemény utáni rész négy külön feladat. Amit tenni tudunk: végignézzük az elképzelését, szétszedjük funkciókra, és tételes ajánlatot adunk. Az is járható út, hogy egy szűkebb első változattal indulunk, és a többi a működés tapasztalataiból épül.

A jegyértékesítő addig kísér, hogy valaki kifizette a belépőt. Onnantól kezdődik az igazi munka: profilkitöltés, helyszíni beléptetés, az esemény alatti vezérlés, majd az esemény utáni kapcsolódás. Ez a két rendszer nem verseng egymással: a jegyértékesítő marad, csak átadja az adatot a saját rendszernek, amiből az meghívót küld.

Annyit, amennyi az adott lépéshez tényleg kell, a többit később. Itt a fiók létrehozásához e-mail cím és jelszó kell, a profil többi része utána jön, az aznapi hangulatkérdések pedig szándékosan csak az esemény közelében – egy fél éve adott válasz már nem mond semmit arról, ma mire vágyik valaki. Egy hosszú, mindent egyszerre bekérő űrlap a leggyorsabb módja annak, hogy a jegyet már megváltó résztvevő félbehagyja a folyamatot, és utána a szervezőnek kelljen utánamennie.

Ez nem kivétel, hanem minden eseményen előfordul, ezért alapból kezelve van. Csak az számít résztvevőnek, aki ténylegesen bejelentkezett a helyszínen, a később érkező pedig beilleszthető a következő körökbe anélkül, hogy az egészet újra kellene kezdeni. Ha egy rendszer ezt nem tudja, azt a szervező fogja kézzel megoldani – pont a legrosszabb pillanatban.

Nem. A rendszer javaslatot készít, amit a szervező megnéz, szükség esetén átír, és ő dönti el, mikor válik láthatóvá. A körök egyesével nyithatók, egy résztvevő kézzel áthelyezhető, a hátralévő körök pedig újragenerálhatók. Élő eseményen mindig lesz olyan helyzet, amit csak ember lát, és a rendszernek ezt meg kell engednie.

A fiók törlése nem elrejtés, hanem anonimizálás: a profiladatok, a fénykép és minden személyhez köthető mező eltűnik, a hírlevél-szolgáltatótól is töröljük a címet. Az esemény statisztikái megmaradnak, de már nem mutatnak konkrét emberre. Egy ismerkedős platformnál ez nem opcionális extra: az adatok érzékenysége miatt ez az alapértelmezett elvárás.

Igen, és ez több, mint kapacitáskérdés. A résztvevők telefonja állandó kapcsolatban van a szerverrel, tehát a kör megnyitásakor mindenki egyszerre kapja meg a helyét, frissítés nélkül. Ha ezt ismételt lekérdezéssel oldanánk meg, a terhelés pont a legrosszabb percben tetőzne, és aki lemarad a frissítésről, az a szervezőhöz megy kérdezni.

Igen. Ugyanez a váz áll szakmai networking eseménynél, konferencia-közösségépítésnél, mentorprogramnál vagy céges csapatépítőnél: regisztráció, profil, helyszíni beléptetés, csoportbeosztás, esemény utáni kapcsolódás. Ami mindig változik, az a beosztás szempontrendszere és az, mi számít sikerült találkozásnak – ezt érdemes az elején végiggondolni, nem a fejlesztés közepén.

Eseményeket kiszolgáló rendszeren gondolkodik?

Ha olyan rendszert tervez, ami nem az irodában fut, hanem élesben, a helyszínen, sok ember telefonján egyszerre, nézzük meg együtt, mi kell hozzá ténylegesen: regisztráció, beléptetés, esemény alatti vezérlés és az utána következő rész. Az első egyeztetés ingyenes, és a végén tételes ajánlatot kap arról, melyik funkció mennyi.

Nézze meg az üzleti rendszer szolgáltatásunkat, vagy hívjon minket a +36 70 430 8133 számon.

Tetszik amit látsz?

Készítsünk együtt egy hasonlóan sikeres projektet a Te vállalkozásodnak is!

Bootstrap logó
Laravel logó
Vue.js logó
HTML5 logó
CSS3 logó
PHP logó
JavaScript logó
WordPress logó
React logó
Node.js logó
MySQL logó
Figma logó