Eatlo 🍽️

QR-based, multi-tenant restaurant ordering SaaS for the Indian market — scan, order, track, pay, no app required.

Live: eatlo.in  |  Role: Solo Developer / Founder  |  Status: In production, onboarding paying restaurants  |  Audience: Independent restaurants & small chains in India

---

Overview

Eatlo replaces the paper-menu-and-shouting-at-waiters experience with a QR-first ordering flow built specifically for the Indian restaurant market: a customer scans the code on their table, browses a live menu in their browser, places an order that lands on a kitchen display in real time, tracks its prep status item-by-item, and pays — all without installing anything. On the other side, kitchen staff manage a live order queue with SLA timers and ticket printing, and owners run the entire operation — menu, staff, tables, discounts, GST reporting — from an admin dashboard.

What makes it interesting technically is that it's a real-time, multi-tenant system with hard financial and regulatory constraints: every restaurant's data must be strictly isolated, every rupee has to be tracked as an exact integer (GST math doesn't forgive floating-point drift), and the system has to stay responsive and consistent across three simultaneous live views (customer, kitchen, admin) of the same order as it moves through its lifecycle. On top of the core ordering loop, the platform layers genuinely product-shaped features — AI-assisted menu onboarding, dynamic wait-time prediction, automatic combo suggestions mined from order history, and a two-tier cancellation system that balances customer flexibility against kitchen workload.

It's built and operated solo, end-to-end: schema design, API, real-time layer, three distinct front-end surfaces, deployment pipeline, and the commercial side (provisioning, billing, support) for a small but real and growing base of paying restaurants in Hyderabad.

Key Features

🧑‍🍳 Customer Experience (/r/:slug/table/:id)

• No-login QR ordering — scanning a table QR starts a session token tied to that table; no account needed
• Live menu with food-type indicators (veg/egg/non-veg dot — an Indian regulatory requirement), spice levels, modifiers/add-ons, combo suggestions, and time-windowed availability (e.g. breakfast-only items)
• Live order tracking — see each item move through pending → confirmed → preparing → ready → served in real time via WebSockets
• Self-service cancellation & replacement — instantly cancel items still in the queue for free, or request cancellation of items already cooking (kitchen approves/rejects, with optional cancellation charge)
• In-session help & bill requests — "call waiter" alerts and "request bill" land on the kitchen/admin dashboards instantly
• Post-meal ratings — rate individual dishes after the session ends, feeding an automatic bestseller algorithm

👨‍🍳 Kitchen Display System (/kitchen)

• Live order queue grouped by table, with per-item status controls and SLA countdown timers showing how close each order is to its expected-ready time
• KOT (Kitchen Order Ticket) printing for thermal printers, with urgency-based visual/audio alerts on overdue tickets
• Table merge/unmerge — combine adjacent tables into one running bill for large groups, splitting back out at the end
• 86'ing items — mark a dish unavailable for a set duration; it auto-restores when the window expires
• Cancellation request approvals — accept or reject customer-initiated cancellations of in-progress items

🧑‍💼 Admin Dashboard (/admin)

• Live operations dashboard — today's stats, a weekly sales chart, and real-time alerts feed
• Menu management — categories, items, modifiers, combos, scheduling (time-of-day availability), bilingual names (English/Telugu)
• AI menu import — upload a photo or paste text of an existing menu; GPT-4o-mini extracts structured items (name, price, food type, spice level, prep time) which the owner reviews and imports in bulk
• Offers engine — percentage / flat / buy-X-get-Y discounts and scrolling announcement banners, both with day-of-week and time-window scheduling
• Staff management with role-based access (owner / manager / kitchen / captain / waiter) and an email-based invite flow
• GST & daily sales reporting, table & QR sheet management, restaurant open/closed toggle, and an onboarding checklist that walks new owners through setup

🛡️ Superadmin / Operator Console (/superadmin)

• Provisions new restaurants, manages client billing (commission or flat monthly), tracks commission payments, and can deactivate/reactivate or hard-delete tenants — gated behind a separate secret-header auth scheme, deliberately kept out of the public nav

A recorded run

Captured on 17 September 2026 against a throwaway local database, with a fictional restaurant created by the provisioning CLI. Every number below is from the run's own logs.

media/recording.mp4 — 62 seconds, unedited: the diner's phone on the left, the kitchen display and owner dashboard on the right, all three updating over Socket.io as one order moves through.

The guest's phone, with the bill split into CGST and SGST.	The kitchen display, the moment the order lands.
The owner dashboard, cash bill requested.	AI menu import, waiting for the owner's review.

What the run measured

• Provisioning a new restaurant: 1.59 s for the whole CLI session (21 prompts, answered by a script), of which 95 ms was server time. Four tables, an owner account, and QR links, ready to use.
• One order, table 3: subtotal ₹800, CGST ₹20, SGST ₹20, total ₹840, with the garlic modifier correctly included in the stored order. 10 Socket.io events observed across the kitchen, admin and session rooms; status changes took 11–16 ms server-side.
• AI menu import: one gpt-4o-mini call on a photo of a fictional menu, 13.2 s round trip, 26,195 input and 1,070 output tokens, about $0.005. It extracted 12 items across 3 categories and captured the +₹20 garlic add-on as a modifier.

And what it exposed. Capturing a real run found four faults that describing one would not have:

• The bill screen leaves a modifier out of its line total — it shows "2 × Butter Naan ₹100" where the stored order correctly has ₹140. The cart and the stored order are right; only that display line is wrong.
• The kitchen display ignores bill:requested — the event reaches the kitchen room, but the page has no handler for it.
• The provisioning CLI reads the restaurant id from the wrong response field, so its follow-up call returns 400 and it falls back to printing a plain menu-import URL.
• The AI import read a deliberately smudged price without flagging it, and the save step silently skipped the one item priced at ₹0, so 11 of 12 reviewed items were saved.

The full event traces are in media/trace-order.json and media/trace-menu-import.json, and the measured facts with the command behind each one are in media/facts.json.

Architecture Overview

flowchart TB
    subgraph Clients["Client Surfaces (React 18 + Vite + Tailwind)"]
        Cust["Customer Web App<br/>/r/:slug/table/:id"]
        Kitchen["Kitchen Display<br/>/kitchen"]
        Admin["Admin Dashboard<br/>/admin"]
        Super["Superadmin Console<br/>/superadmin"]
    end

    subgraph Server["Express API (Node.js)"]
        REST["REST Routes<br/>auth · public · kitchen · admin · ratings · superadmin"]
        MW["Middleware<br/>JWT auth · RBAC · rate limiting · ownership checks"]
        SocketSrv["Socket.io Server<br/>session / kitchen / admin rooms"]
        Jobs["Background Jobs<br/>86-restore · combo recompute · overdue-order sweep"]
    end

    subgraph Data["Data Layer"]
        PG[("PostgreSQL<br/>raw SQL via pg, multi-tenant by restaurant_id")]
    end

    subgraph External["External Services"]
        OpenAI["OpenAI gpt-4o-mini<br/>AI menu import"]
        Cloudinary["Cloudinary<br/>image hosting"]
        Resend["Resend / Nodemailer<br/>transactional email"]
        Sentry["Sentry<br/>error tracking"]
    end

    Cust <-->|HTTPS + WebSocket| REST
    Kitchen <-->|HTTPS + WebSocket| REST
    Admin <-->|HTTPS + WebSocket| REST
    Super -->|HTTPS, secret-header auth| REST

    REST --> MW --> PG
    REST <--> SocketSrv
    SocketSrv <--> Cust
    SocketSrv <--> Kitchen
    SocketSrv <--> Admin
    Jobs --> PG
    Jobs --> SocketSrv

    REST --> OpenAI
    REST --> Cloudinary
    REST --> Resend
    Server --> Sentry

The system is a modular monolith: one Express app serves four distinct front-ends and hosts the Socket.io server in the same process, sharing a single connection pool to PostgreSQL. That single-process design keeps an order's state changes — REST write → DB commit → socket broadcast — trivially consistent, which matters a lot when three different screens need to agree on what "ready" means within milliseconds. Real-time fan-out is room-based (session:{token}, restaurant:{id}:kitchen, restaurant:{id}:admin) so each surface only receives events relevant to it, and a small set of interval-based background jobs (86-restore, combo recomputation, overdue-order detection) run inside the same process and push their results back out over the same socket layer.

Tech Stack

Category	Technology	Why
Frontend	React 18, Vite, React Router v6, Tailwind CSS	Fast dev loop and small bundles for a mobile-first ordering UI that has to load instantly from a QR scan on restaurant Wi-Fi
Backend	Node.js, Express	Single language across the stack; mature ecosystem for REST + WebSockets in one process
Database	PostgreSQL, raw SQL via pg (no ORM)	Full control over query plans and joins for reporting (GST, daily sales, combo mining) — and integer-only arithmetic for money is easier to guarantee without an ORM's type coercion in the way
Real-time	Socket.io v4	Room-based broadcast model maps cleanly onto "restaurant kitchen", "restaurant admin", "customer session" — with automatic reconnection on flaky restaurant Wi-Fi
Auth	JWT (7-day) + bcryptjs + revocation list	Stateless verification for normal requests, with a jti-based blacklist so logout / password-reset can still invalidate a token immediately
AI	OpenAI gpt-4o-mini	Cheap, fast structured-output model — good enough for the bounded task of turning a photo/text menu into validated JSON, with strict server-side schema checking on the result
Media	Cloudinary	Offloads image transformation/CDN delivery for menu photos and logos
Email	Resend / Nodemailer	Transactional flows — verification, password reset, staff invites
Monitoring	Sentry	Production error visibility for a solo-maintained system
Deployment	Railway (API + DB), Vercel (frontend + marketing)	Push-to-deploy pipeline suited to a small team shipping multiple times a week

Database Schema

erDiagram
    RESTAURANTS ||--o{ RESTAURANT_TABLES : has
    RESTAURANTS ||--o{ STAFF : employs
    RESTAURANTS ||--o{ MENU_CATEGORIES : organizes
    RESTAURANTS ||--o{ MENU_ITEMS : sells
    RESTAURANTS ||--o{ DISCOUNTS : offers
    RESTAURANTS ||--o{ ANNOUNCEMENTS : publishes

    MENU_CATEGORIES ||--o{ MENU_ITEMS : contains
    MENU_ITEMS ||--o{ ITEM_MODIFIERS : has
    MENU_ITEMS ||--o{ ITEM_RATINGS : receives
    MENU_ITEMS ||--o{ COMBO_SUGGESTIONS : "suggests / triggers"

    RESTAURANT_TABLES ||--o{ SESSIONS : seats
    RESTAURANT_TABLES ||--o{ TABLE_MERGES : "merged in"

    SESSIONS ||--o{ ORDERS : produces
    SESSIONS ||--o{ PAYMENTS : settles
    SESSIONS ||--o{ ITEM_RATINGS : "rates after"

    ORDERS ||--o{ ORDER_ITEMS : contains
    ORDERS }o--o| DISCOUNTS : "discounted by"
    ORDER_ITEMS ||--o{ ORDER_ITEM_MODIFIERS : customised_by
    ORDER_ITEMS ||--o{ CANCELLATION_REQUESTS : "may have"
    ORDER_ITEMS ||--o{ ITEM_RATINGS : rated_in

    DISCOUNTS ||--o{ DISCOUNT_TARGETS : "scoped to"

    RESTAURANTS {
        uuid id PK
        string slug UK
        int gst_rate
        string gst_type
        boolean is_active
    }
    MENU_ITEMS {
        uuid id PK
        uuid restaurant_id FK
        uuid category_id FK
        int price "paise, integer"
        string food_type "veg | nonveg | egg"
        boolean eighty_sixed
        numeric avg_rating
        int rating_count
    }
    ORDERS {
        uuid id PK
        uuid session_id FK
        uuid table_id FK
        string status
        int subtotal
        int gst_amount
        int total_amount
        int discount_amount
        timestamptz expected_ready_at
    }
    ORDER_ITEMS {
        uuid id PK
        uuid order_id FK
        uuid menu_item_id FK
        int item_price "snapshot at order time"
        string status
        int cancellation_charge
        uuid replaced_by_item_id FK
    }
    SESSIONS {
        uuid id PK
        uuid restaurant_id FK
        uuid table_id FK
        uuid session_token UK
        string order_type
        boolean is_active
    }
    DISCOUNTS {
        uuid id PK
        string discount_type "percentage | flat | bxgy"
        int discount_value
        jsonb active_days
        time active_from
        time active_until
    }
    CANCELLATION_REQUESTS {
        uuid id PK
        uuid order_item_id FK
        string reason
        string status "pending | approved | rejected"
        boolean charge_waived
    }

The schema spans 16 incremental migrations (each IF NOT EXISTS/idempotent, so they can run safely on every deploy). Every tenant-scoped table carries a restaurant_id foreign key with ON DELETE CASCADE, which is the backbone of the row-level multi-tenancy model — see Key Technical Decisions below. All monetary columns are stored as integer paise, and a Postgres trigger on item_ratings automatically recomputes each dish's average rating and flips its is_bestseller flag once it crosses a quality threshold — business logic that lives in the database because it has to be correct regardless of which code path inserts a rating.

API Design

All routes are versionless and namespaced by audience. 120 endpoints exist in total (118 router routes plus two health checks, counted from the code on 17 September 2026); the most representative are grouped below (full reference in API_DOCUMENTATION.md).

Auth — /api/auth

• POST /login — staff login (rate-limited)
• GET /me — current staff profile
• POST /logout — revokes the current JWT
• POST /forgot-password / POST /reset-password — email-based reset flow
• POST /accept-invite — staff completes an email invite

Public / Customer — /api

• POST /session/start — start (or resume) a table session from a QR scan
• GET /menu/:slug — restaurant's live, schedule-aware menu
• POST /orders — place an order (server snapshots prices, applies discounts, calculates GST)
• GET /orders/session/:token — all orders for the active session, for live tracking
• POST /help-alert / POST /bill/request — call-waiter and request-bill actions
• POST /orders/:orderId/items/:itemId/cancel — instant free cancellation (pre-kitchen items)
• POST /orders/:orderId/items/:itemId/cancel-request — request cancellation of in-progress items

Kitchen — /api/kitchen

• GET /orders — live order queue for the restaurant
• PATCH /orders/:orderId/status / PATCH /items/:itemId/status — move items through the prep lifecycle
• POST /tables/merge / DELETE /tables/merge/:mergeId — merge/unmerge tables
• PATCH /menu-items/:menuItemId/86 — mark an item temporarily unavailable
• PATCH /cancel-requests/:requestId/approve — approve or reject a customer cancellation request

Admin — /api/admin

• GET /dashboard — today's stats, weekly chart data, live alerts
• GET/POST/PUT/DELETE /menu/items — full menu CRUD, plus /menu/import/parse and /menu/import/save for AI-assisted bulk import
• GET/POST/PATCH/DELETE /discounts and /announcements — offers engine
• GET /reports/gst / GET /reports/daily — tax and sales reporting
• POST /upload-image / POST /upload-logo — Cloudinary-backed media upload

Superadmin — /api/superadmin (secret-header auth, separate from staff JWT)

• POST /provision — create a new tenant restaurant
• GET /clients / PATCH /clients/:id — client roster and billing management
• GET /commission / POST /commission/:id/mark-paid — commission tracking

Real-Time Event Flow

Order status changes are the highest-frequency real-time event in the system — they have to reach the customer's phone, the kitchen display, and the admin dashboard simultaneously and in the correct order:

sequenceDiagram
    participant C as Customer App
    participant API as Express API
    participant DB as PostgreSQL
    participant IO as Socket.io
    participant K as Kitchen Display
    participant A as Admin Dashboard

    C->>API: POST /orders (session_token, items)
    API->>DB: BEGIN — snapshot prices, apply discount, calc GST
    DB-->>API: order + order_items committed
    API-->>C: 201 Created (order summary)
    API->>IO: emit "order:new"
    IO-->>K: order:new (kitchen room)
    IO-->>A: order:new (admin room)

    K->>API: PATCH /kitchen/items/:id/status ("preparing")
    API->>DB: UPDATE order_items SET status, recalc order totals
    API->>IO: emit "item:updated" / "order:updated"
    IO-->>C: item:updated (session room) — live tracker updates
    IO-->>A: order:updated (admin room)

    Note over IO,K: Background job — overdue sweep (every 60s)
    IO-->>K: order:overdue (if expected_ready_at has passed)

Rooms are joined with credentials: customers join session:{token} with their session token, while kitchen/admin clients must present a valid staff JWT whose restaurantId matches the room they're requesting — preventing one restaurant's staff from listening in on another's kitchen feed.

Key Technical Decisions

1. Raw SQL over an ORM Decision: All database access goes through parameterised queries via the pg driver — no Sequelize/Prisma/TypeORM. Why: Reports (GST breakdowns, daily sales, combo mining from 90 days of order history) need hand-tuned joins and aggregates that are awkward to express — and easy to get subtly wrong — through an ORM's query builder. Raw SQL also keeps the integer-paise contract explicit at every boundary, with no risk of an ORM silently coercing a monetary column to a float. Trade-off: More boilerplate and manual migration management (see decision 2), in exchange for predictable query plans and zero "magic" between the code and what actually runs against the database.

2. Inline, idempotent migrations Decision: Every schema change is a numbered .sql file using CREATE TABLE IF NOT EXISTS / ALTER TABLE ... ADD COLUMN IF NOT EXISTS, runnable repeatedly without error. Why: The deploy target (Railway) doesn't run a separate migration step — migrations execute as part of application startup. Idempotency means a redeploy never fails because a migration "already ran," which removes an entire class of deploy-time incidents for a solo-maintained production system. Trade-off: No down-migrations or rollback tooling; schema evolution is strictly additive. Acceptable for a system at this stage, but it's a deliberate scope cut that would need revisiting at larger scale.

3. Multi-tenancy via shared schema + row-level scoping + defense-in-depth ownership checks Decision: All restaurants share one schema; every tenant-owned table carries restaurant_id, every query filters on it (taken from the authenticated staff member's JWT, never from client input), and a separate requireOwnership middleware re-verifies that a requested resource actually belongs to the caller's restaurant before the handler runs. Why: Shared-schema multi-tenancy is operationally far simpler than per-tenant schemas or databases at this scale — one connection pool, one migration path, trivial cross-tenant analytics for the superadmin console. The ownership middleware exists specifically so that if a query is ever mis-scoped, the request still 403s rather than leaking another restaurant's data. Trade-off: Every new table and query has to remember to scope by restaurant_id — a single missed filter is a tenant-isolation bug. The ownership middleware is the safety net for exactly that human-error case.

4. Server-snapshotted pricing inside a DB transaction Decision: POST /orders never trusts client-supplied prices, modifier costs, or discounts. It re-fetches each menu item and modifier from the database inside a transaction, computes the subtotal, resolves the best applicable discount, calculates GST (split into CGST/SGST where required), and only then commits — all before emitting any socket event. Why: This is the financial core of the product; a race condition or a trusted client value here is a direct path to revenue loss or tax-reporting errors. Wrapping it in a transaction also guarantees the kitchen never sees an order that the database doesn't durably have. Trade-off: Slightly higher latency on order placement (multiple round-trips inside one transaction) in exchange for correctness guarantees that can't be bypassed from the client.

5. Two-tier cancellation model Decision: Items still pending/confirmed can be cancelled instantly and for free by the customer. Items already preparing/ready instead create a cancellation_request that the kitchen must explicitly approve or reject — optionally waiving or applying a cancellation charge — and the order's totals are recalculated transactionally either way. Why: A flat "always allow free cancellation" policy is open to abuse (cancel after the kitchen has already cooked the food); a flat "no cancellation" policy is bad for customers who misordered. Splitting the policy by where the item already is in the kitchen workflow aligns incentives for both sides. Trade-off: Meaningfully more state to track (cancellation_requests, charge fields, replacement links) than a single cancel path — but it directly reflects how a real kitchen actually operates.

6. JWT with a server-side revocation list Decision: Tokens are stateless JWTs (7-day expiry, payload includes a unique jti), but logout and password-reset additionally write that jti to a blacklist that authenticate checks on every request. Why: Pure stateless JWTs can't be invalidated before they expire — a real problem for "log out everywhere" and "I think my password leaked" scenarios. A blacklist keyed on a short random ID (rather than tracking full sessions) keeps the lookup cheap while closing that gap. Trade-off: Adds one extra check (and a cleanup job for expired entries) to every authenticated request — a small, deliberate cost for the ability to actually revoke access on demand.

Performance & Scale Considerations

• Targeted indexes on every high-traffic lookup path: item_modifiers, table_merges, discounts, cancellation_requests, login_attempts, and token_blacklist all have composite indexes matching their actual query patterns (e.g. (restaurant_id, is_active), (email, attempted_at))
• Connection pooling via pg.Pool, shared across REST handlers, the socket layer, and background jobs
• Tiered rate limiting — distinct limits for login, password-reset, order placement, AI menu import, and general public traffic, with a no-op bypass in development so local testing isn't throttled
• Background jobs run on intervals, not per-request: 86'd-item restoration (5 min), combo-suggestion recomputation from 90 days of history (6 hr), and overdue-order detection (60 s) — keeping expensive aggregate queries off the request path
• Server-side schedule evaluation (menu/category/discount time windows) computed once per request in IST, rather than shipping timezone logic to the client

Testing

The project relies on a tight, fast iteration loop (115 commits across roughly two and a half months of active development) backed by a seeded demo tenant — Spice Garden — that mirrors production data shape (tables, categories, menu items, staff roles) closely enough to exercise every flow, from QR scan through kitchen approval to GST reporting, before it ships.

What I Learned

• Real-time consistency is harder than real-time delivery. Getting an event to a socket room is the easy part; making sure the customer's tracker, the kitchen queue, and the admin dashboard all agree on an order's state — including edge cases like "the last item in an order just got cancelled, so the order itself should auto-cancel" — required careful transactional design and recalculation logic, not just io.emit.
• Money has to be an integer, always, with no exceptions. Modelling every price, modifier, discount, and tax component as integer paise from the database schema all the way to the UI eliminated an entire category of rounding bugs that would otherwise surface as "the bill doesn't add up" — the worst possible bug for a payments-adjacent product to ship.
• Multi-tenancy bugs are isolation bugs, and they hide well. A query that "happens to work" in a single-tenant demo can silently leak data across tenants in production. Building a dedicated, allow-listed ownership-check middleware as a second line of defense — independent of remembering to filter every query — was a direct response to that risk.
• Solo-founder constraints shape architecture, for the better. Choosing a modular monolith over microservices, idempotent inline migrations over a separate migration pipeline, and managed services (Railway, Vercel, Cloudinary, Resend, Sentry) over self-hosted infrastructure wasn't a compromise — it's what let one person ship, operate, and support real paying customers without a platform team.

Status & Roadmap

Status: In production. Live at eatlo.in, actively onboarding paying restaurants in Hyderabad, with continuous weekly shipping (115 commits since the initial commit).

Recently shipped: thermal KOT/bill printing with urgency timers and audio alerts, animated landing-page feature demos, an audited and hardened cancellation/replacement system, and live payment-request syncing on the admin dashboard.

Planned:

• Expanding payment methods beyond UPI/cash/card capture (deeper gateway integration)
• Broader analytics for owners (beyond GST/daily reports — trend and cohort views)
• Multi-language menu support beyond the current English/Telugu pairing
• Expansion beyond Hyderabad as the operator base grows