Qber: kulcs nélküli autóbérlés egy Firebase-projekten és három alkalmazáson

A termék: nyomkövető az autóban, app a tulajdonos zsebében

A Qber a NordiQ Solutions peer-to-peer autóbérlési platformja távoli átadással. A tulajdonos a webshopban rendel egy Qber Remote eszközt havi vagy éves előfizetéssel, egy szerelő beépíti, és az autó ettől kezdve jelenti a pozícióját és a telemetriáját, a tulajdonos telefonjáról pedig zárási és nyitási parancsokat fogad.

A hardver egy Teltonika nyomkövető CAN-adapterrel, amelyet a Flespi telematikai platformon keresztül érünk el. Az ajtóparancs autótól függően vagy egy relékimenet, vagy egy CAN-buszos utasítás; az appnak nem kell tudnia, melyik. Maga a bérlés ezekre a parancsokra épül: a nyitás bérlést indít, a zárás lezárja, a kilométeróra-állást és az üzemanyagszintet pedig a bérlés elején és végén a szerver olvassa ki a telemetriából.

Egy backend, három bejárat

Háromféle ember használja a rendszert, és mindegyiknek egészen másra van szüksége. A tulajdonos mobilappot akar, amelyben látja az autót, és bérlést tud indítani. A NordiQ munkatársainak háttérrendszer kell az ügyfelekhez, előfizetésekhez, eszközökhöz, SIM-kártyákhoz, QR-matricákhoz, ticketekhez és értesítésekhez. A bérlő pedig be akar ülni egy autóba, ami nem az övé – a lehető legkevesebb akadállyal, és anélkül, hogy bármilyen appot telepítenie kellene.

Ezért egyetlen Firebase-projekten három app fut, és az adatok tulajdonlásának határait pontosan meghúztuk. A Flutter tulajdonosi appé és a Cloud Functionsé a felhasználók, járművek, bérlések, ticketek és értesítések. A Next.js adminé az ügyfelek, előfizetések, eszközök, SIM-kártyák, QR-kódok és az audit log. A bérlői portálé az átadások. Mindegyik app olvashatja, ami a másiké, de csak a sajátjába ír, a háttérrendszer adatai pedig kliensből egyáltalán nem olvashatók.

Telematika saját szerver nélkül

A Flespi az eszközök üzeneteit egy Cloud Function-webhookba streameli, amely a legfrissebb telemetriát a Firestore-ba írja; az app erre a dokumentumra iratkozik fel. A parancsok az ellenkező irányba mennek: egy callable function ellenőrzi, hogy a hívó a kocsi tulajdonosa-e, elküldi a relé- vagy CAN-parancsot a Flespin keresztül, naplózza, majd elindítja vagy lezárja a bérlést. A telemetriakártyák, szervizintervallumok és figyelmeztetések ugyanebből a streamből jönnek, egy táblázat alapján leképezve, amelyet az ügyfél töltött ki; a hibakódokat igény szerint kérdezzük le.

Egy döntés triviálisnak tűnik, de nem volt az. A Flespi-streamek üzeneteket visznek, kapcsolati állapotot soha, így az első verzióban minden autó folyamatosan online-nak látszott. Fontolgattunk egy platform-webhookot a kapcsolódási eseményekre, de elvetettük, mert nem érte meg a plusz mozgó alkatrészeket; egy autó most akkor számít online-nak, ha az utolsó üzenete tíz percnél frissebb. Az ilyen döntésektől marad kicsi egy kis rendszer.

Előbb audit, aztán háttérrendszer

Mielőtt nekiálltunk az adminnak, teljes auditot végeztünk a mobilappon és a Cloud Functionsön – ugyanazt az átvilágítást, amit egy átvett kódbázison is elvégeznénk. Megtalálta azokat a gyors megoldásokat, amelyek egy sietve elkészült első verzióban összegyűlnek, és a fő tanulsága az volt, hogy ami egy egyfelhasználós mobilappban elfogadható minta, az nem lehet alapja egy olyan háttérrendszernek, amelyben a munkatársak minden ügyfélhez hozzáférnek.

Ezért az admint nem foltoztuk, hanem más modellre építettük: az adatokat és a külső szolgáltatásokat kizárólag a szerver éri el, a munkatársi hozzáférés szerepköralapú, és minden kérésnél újra ellenőrizzük, minden módosítást validálunk és audit logba írunk, a böngészőben pedig nincs semmi, amit érdemes volna ellopni. Az audit fennmaradó tételei egy követett listára kerültek javítva, részben javítva vagy nyitott státusszal – ezt többre tartjuk, mint egy homályos ígéretet, hogy majd később megerősítjük.

Bérlők fiók nélkül

A bérlő egyszer találkozik a Qberrel, a szélvédőnél. A portál pontosan erre készült: nincs regisztráció, nincs jelszó. A bérlő beolvassa a QR-matricát, beírja a tulajdonostól kapott rövid bérlési kódot, és kap egy munkamenetet arra az egy átadásra. Innen egy státuszvezérelt oldal vezeti végig öt, előre kijelölt átvételi fotón, az adatain és a bérleti szerződésen; visszaadáskor még hat fotón.

A szerződést nem aláírják, hanem elfogadják. A bérlő elolvassa a teljes magyar szerződést – ugyanazt a sablont ugyanazokkal az értékekkel, mint az e-mailben kiküldött PDF –, és megnyomja az elfogadás gombot. A portál eltárolja, mikor történt, melyik sablonverziót látta, és a pontos szöveg hash-ét, amely megegyezik a legenerált PDF-en szereplő dokumentum-hash-sel. Először rajzolt aláírást és tulajdonosi aláíró oldalt is építettünk; mindkettőt még aznap kidobtuk, mert az appban a bérlés indítása maga a tulajdonos jóváhagyása, egy telefonon odafirkantott aláírás pedig kevesebbet bizonyít, mint egy hash.

A tulajdonos appja soha nem ír átadást. A portál API-ját kéri meg, hogy hozzon létre vagy mondjon le egyet, a saját átadásait a Firestore-ból olvassa, és ha a bérlő még nem fogadta el a szerződést, nyitás előtt megerősítést kér. A nyitás aktívra állítja az átadást, a zárás lezárja; a szerződés PDF-jét mindkét fél e-mailben kapja meg.

Unalmas döntések, amelyekkel tartható a tempó

Semmi egzotikus nincs a stackben. A tulajdonosi app Flutter, kézzel írt Riverpod providerekkel és go_routerrel; az admin és a portál Next.js 16 Server Actions, shadcn/ui, Zod és next-intl alapokon, Vercelre telepítve, cron jobokkal a napi Firestore-backuphoz és az integrációk szinkronjához. Mindhárom app kétnyelvű, magyar alapértelmezéssel, az első képernyőtől kezdve.

Az adminhoz rendes Vitest-tesztkészlet tartozik a sémákra, mapperekre, actionökre és a kérések validálására; a portálon célzott tesztek futnak a bérlői munkamenetre, a szerződés renderelésére és a kódokra. A mobilappnak még nincsenek valódi automatizált tesztjei, és ezt ki is mondjuk: ott a következő lépésnek Firebase-emulátoron futó widget teszteknek kellene lenniük, nem egy újabb funkciónak.

Hol tart most

A platform még az elején tart. Az onboarding úgy van felállítva, hogy az admin Kanban-tábláján fusson a kifizetett rendeléstől az aktív előfizetésig, a munkatársi háttérrendszer és a bérlői portál telepítve van, a tulajdonosi app pedig a tizenhatodik buildnél tart. Néhány dolog még nyitott, és ezt így is jelezzük: a szerződés szövege jogi átnézésre vár, a crash reporting és az áruházi kiadáshoz szükséges aláírás nincs kész, a jogosítványfotók megőrzési idejét érvényesítő job pedig még hátravan.

Ügyfél- és járműszámokat nem közlünk, mert a termék korai fázisban van, és az ügyfélé. Amit meg tudunk mutatni, az a felépítés: egy hardverre épülő bérlési platform három kis appként egyetlen backenden, nagyjából három hónap alatt, olyan háttérrendszerrel, amelyet egy korai audit tanulságai köré terveztünk.