Paddy's Burger

A brief azt mondta: "weboldal." A probléma mást.

A Paddy's Burger egy nyíregyházi smash burger étterem, növekvő helyi rajongótáborral. A kiszállítás Wolton és Foodorán fut, az jól működik. De a helybeni átvételre nem volt digitális csatorna. Nem lehetett előre rendelni. Nem volt közvetlen vendégkapcsolat. Sem email cím. Sem rendeléstörténet. Sem mód a visszatérő vendégek jutalmazására.

Egy landing page megoldotta volna a briefet. A problémát nem.

Amit tényleg készítettem

Négy rendszer, egy kódbázis:

1. Előrendelési folyamat, ami közvetlen csatornát ad az étteremnek a helybeni átvételes rendelésekre.
2. Hűségprogram, ahol a visszatérő vendégek pontokat gyűjtenek és QR-kóddal váltják be a jutalmaikat.
3. Staff dashboard, ami valós időben mutatja a konyhának a beérkező rendeléseket.
4. Catering modul (fejlesztés alatt), ami új piacot nyit: rendezvények, irodák, tömeges rendelések.

Az előrendelés és a hűségprogram a meglévő vendégeket szolgálja jobban. A catering teljesen új célközönséget ér el. Minden funkció valós szükségletből nőtt ki, nem feature-listából.

Design döntések

A legtöbb food brand pirosat, narancsot, sárgát használ. A Paddy's az ellenkező irányba ment: telített kék, ami kontraszton keresztül dobja meg az ételfotókat. Ha minden versenytárs meleg tónusú, egy hűvös paletta azonnali felismerhetőséget teremt.

A tipográfia erős és sűrű. A címsorok mobilon is távolról olvashatók. A szövegtörzs olvasható marad anélkül, hogy versenyezne a képekkel. A vizuális hierarchia dolgozik: először a burgert látod, aztán a nevet, aztán az árat.

A GSAP kezeli a scroll-alapú animációkat. Szekciók belépéskor jelennek meg, az étlap elemei 50ms-os késleltetéssel lépcsőznek, a hero finoman parallaxol. A mozgás célja: a figyelmet a rendelési CTA felé terelni. Az animációk minden eszközön ugyanazon a feszes 350ms-os alaptempón futnak. A ScrollTrigger küszöbök mobilra (80% viewport) és desktopra (75%) külön vannak hangolva.

Minden képernyő mobile-first. A forgalom nagy része közösségi médiából érkező linkekről jön, telefonon.

Előrendelés

Az első ösztön egy egyszerű form volt: név, telefon, tételek, időpont. De a mintázat, amit éttermeknél folyamatosan láttam, mindig ugyanaz. A vendég túl sokat rendel, irreális időpontot választ, és a konyhának nincs visszaszólási lehetősége.

A folyamat progressive disclosure-t használ. Először burgereket választasz. Kiegészítők csak utána jelennek meg. Aztán az átvételi idő. Aztán a kontakt adatok. Minden lépés szűkíti a lehetőségeket. A vendég sosem lát hosszú formot. A konyha sosem kap teljesíthetetlen rendelést.

Az átvételi idősávokat a szerver generálja az étterem tényleges nyitvatartásából, 30 perces felkészülési pufferrel és 15 perces intervallumokkal. A rendszer blokkolja a nyitvatartáson kívüli kéréseket.

Fizetés után a vendég egy valós idejű követőoldalra kerül. Egy körkörös haladásjelző vizualizálja az öt lépéses utat, érzékelt haladás-térképezéssel: a gyűrű beküldéskor 5%-ra ugrik, elfogadáskor 30%-ra, készítés közben 65%-ra, készre 100%-ra. Egy eltelt idő számláló mutatja a rendelés óta eltelt perceket. A rendelés részletei lenyitható szekcióban jelennek meg, tételképekkel és árakkal.

A konyha azonnali értesítést kap. Telefonálás nem szükséges.

Két részlet, ami tovább tartott a vártnál. A magyar betétdíj rendszer (DRS) palackonként 50 Ft-ot ad, és a tételnek láthatónak, különállónak és jogszabályilag helyesnek kell lennie. A magyar telefonszámok legalább hatféle formátumban érkeznek; a parser mindet normalizálja validálás előtt.

Hat automatizált email követi a rendelés életciklusát: visszaigazolás tételes számlával, staff értesítés vendégadatokkal, elfogadási értesítés, készítési frissítés, átvételre kész az étterem címével és telefonszámával, és lemondási üzenet ha szükséges. Mind React Email-ben sablonozva, mind magyarul, mind az oldal vizuális nyelvét követve.

Hűségprogram

A papír pecsétkártyák elvesznek. Az app-alapú programoknál a letöltés a súrlódás. A középút: webes pontrendszer, fiókhoz kötve.

A regisztráció a Paddy's Clubon keresztül megy, Google OAuth-tal az alacsony súrlódásért vagy email/jelszóval alternatívaként. Az auth folyamat tartalmaz valós idejű jelszóvalidálást (8+ karakter, vegyes kis/nagybetű, számok), email megerősítést 6-jegyű OTP kóddal, és rate limitinget: percenként 5 próbálkozás, fiókzárolás 10 sikertelen kísérlet után, látható visszaszámlálóval.

Minden rendelés pontot ér, nagyjából 140 Ft-onként egyet. Hét jutalomszint, sültkrumplitól 5 pontért a Paddy's Special burgerig 18-ért. Beváltáskor a rendszer egyedi QR-kódot generál, 7 napos érvényességgel. A személyzet a pultnál leolvassa. Nincs papír, nincs elfelejtett kártya, nincs manuális nyilvántartás.

A vendég radiális haladásjelzőt lát a következő jutalomig. Beváltáskor: konfetti a márka színeiben (kék, sárga, zöld) lő ki a képernyő mindkét oldaláról. Apró részletek. De a tranzakcióból szokást csinálnak.

Staff dashboard

A staff dashboard más problémát old meg. A vendégnek tisztaság és egyszerűség kell. A konyhának sűrűség és sebesség.

A rendelések öt állapoton haladnak át: új, elfogadva, készítés alatt, kész, átvéve. Minden állapot színkódolt, valós idejű számolókkal. A konyha nézet mindent eltávolít ami nem lényeges: nagy betűméret, ragadós fejléc, élő óra, túlméretezett státuszjelzők.

A személyzet egyetlen érintéssel viszi tovább a rendelést. A rendszer minden állapotváltást naplóz időbélyeggel és felhasználó-azonosítással.

A hűségprogram kezelése ugyanebben a dashboardban él: vendégkeresés, QR-validálás, pontkorrekciók. Egy felület mindenre, amihez a személyzet naponta hozzányúl.

Architektúra

A tech döntések a követelményekből jöttek.

Convex backendként. A konyha dashboard és a rendeléskövetés egyaránt valós idejű adatot igényel. Amikor a vendég lead egy rendelést, a konyha azonnal látja. Amikor a személyzet készre jelöli, a követőoldal frissítés nélkül frissül. Egy hagyományos REST API pollinggal késleltetést és komplexitást adott volna. A Convex valós idejű szinkront, szerver-oldali mutációkat, ütemezett jobokat és beépített rate limitinget ad egyetlen rendszerben.

Zustand kliens-oldali state-re. A kosárnak túl kell élnie az oldal-újratöltést, és komplex beágyazott adatot kell tárolnia: tételek, variánsok, kiegészítők, betétdíjak, átvételi preferenciák. A Zustand persistence middleware-rel ezt tisztán kezeli. A szerver state a Convex-ben marad. A kliens state a Zustand-ban. A határ tiszta.

Next.js 16 React 19-cel a frontendon. A szerver komponensek kezelik a statikus részeket (étlap, brand oldalak, jogi szövegek). A kliens komponensek az interaktív folyamatokat (rendelés, dashboard, hűségprogram). Ez a szétválasztás kicsiben tartja a kezdeti bundle-t, míg az interaktív részek igény szerint töltődnek.

Resend React Email-lel tranzakciós üzenetekre. Hat email típus, mind React komponensekként sablonozva, mind az oldal design nyelvét követve.

GSAP lazy loadinggal. Az animációs kód dinamikusan importálódik, csak szükség esetén töltődik. A ticker 60fps-t céloz. A batchelés trigger-enként 5 elemnél sapkáz a jank ellen. GPU-gyorsított transzformok force3D-vel, befejezés után takarítva a memóriaszivárgás ellen.

Catering

A backend kész: 14 napos dátumválasztó, délelőtti és délutáni sávok, szállítási adatok, számlázás, mennyiségalapú kedvezmények, ingyenes szállítás minimum küszöb felett. Szállítási és átvételi teljesítést egyaránt támogat.

Az étterem az operatív munkafolyamatot véglegesíti az élesítés előtt.

A láthatatlan rész

Kívülről ez egy éttermi weboldal, kék színvilággal és gusztusos ételfotókkal.

Alatta: idősáv-generálás élő nyitvatartásból, betétdíj-számítás italonként, öt állapotú rendelési pipeline valós idejű szinkronnal, QR-kódok 7 napos lejárattal és staff-oldali validálással, hat lépéses email automatizáció, érzékelt haladás-térképezés körkörös trackeren, rate-limitált auth fiókzárolással, és konfetti ami akkor lő, amikor kiérdemelsz egy ingyen burgert.

A vendég egy étlapot és egy gombot lát. A konyha pontosan azt, amire szüksége van. Minden, ami a kettő között van, infrastruktúra.