Walk-In Queue & Mobile Ordering Platform
2026 - Today
A live walk in queue and mobile ordering marketplace, with four clients generated from one API contract.
- NestJS
- Next.js
- React Native
- Prisma
- Socket.IO
- Stripe Connect
My role: Lead developer and architect
A marketplace platform that covers two very different jobs with one backend. Service venues run a live walk in queue, where customers join remotely, watch their position move and get reminded when they are next. Food and drink venues take mobile pre orders from a menu with modifier groups, then work them through a preparation board. The system is a NestJS API on PostgreSQL and Prisma, three Next.js applications for customers, partners and platform administrators, and a React Native client built on the same generated API layer.
The API is the contract. It publishes an OpenAPI 3 document and every client is generated from it, so a change to a route or a DTO surfaces as a type error in all four frontends rather than as a runtime surprise. Live updates run through a Socket.IO gateway that authenticates two different kinds of caller and puts each in only the rooms it is entitled to, one set of rooms per customer, partner, shop and worker for signed in users, and a separate path for paired hardware. That hardware path drives in store thermal ticket printing: a terminal pairs with a short lived code, then authenticates with a hashed device token, receives structured ticket payloads it renders locally, and reports paper out state, battery level and app version back. A partial unique index guarantees at most one automatic print job per order, with partner reprints recorded as a distinct source.
Payment state was the other design problem. The two verticals resolve entitlement differently, so both go through a single function that derives the plan actually in force from subscription state, trial and grace period, rather than each caller reimplementing the rules. Stripe Connect handles payouts, and a persisted webhook event ledger makes order and payment transitions idempotent, so a retried card payment recovers a failed order instead of duplicating it. Queue mechanics get the same care, with automatic move up on cancellation while freed slots stay visible until resolved, templated WhatsApp notifications for reminders and reschedules, worker rostering with shifts, breaks and days off, a kiosk mode for walk ins at the counter, and reporting that aggregates in SQL rather than in application memory. I set up all five repositories, wrote the product, schema and API specification the build follows, and led the delivery hands on, working through the implementation and reviewing every part of it.