Background
Many independent restaurants still rely on printed menus and manual order taking. That slows service, creates language friction for tourists, and gives owners little visibility into what is selling.
What we built
We built Eazmenu as a multi-app platform:
- A customer web app that opens from a table QR code.
- An admin dashboard where restaurant staff manage menus, tables, orders, branding, and translations.
- A backend API that handles menu delivery, order lifecycle, security checks, and optional payments.
- A shared package used by all apps for one source of truth for database schema and API types.
Customer experience
A guest scans a QR code at the table and lands directly on the digital menu. The app validates the QR input, resolves the preferred language, and loads menu data tied to that table and restaurant.
From there, the guest can:
- Browse categories and featured dishes.
- Switch language.
- Add items to cart and place an order.
- Track active orders from the same session.
The menu UI supports restaurant branding, including colors, fonts, hero images, logo, and chef message.
Admin experience
Restaurant staff use the admin app to run day-to-day operations:
- Manage restaurants, categories, menu items, and tables.
- Monitor incoming orders in real time.
- Update order status as service progresses.
- Configure available languages and translation coverage.
- Run one-click translation from primary language to secondary languages.
- Preview the customer menu in an authenticated preview mode.
Technical approach
The platform is split into focused services and frontends, with shared models across all projects to avoid contract drift.
Key implementation choices:
- QR menu endpoints support redirect and JSON modes.
- Order creation validates table ownership and table active state.
- Server computes totals from database prices, so client-side price tampering does not affect billing.
- Realtime updates use database change subscriptions, so order events appear in admin without refresh.
- Payment routes integrate with Stripe when configured and fail safely when payment config is absent.
Security and reliability decisions
We treated trust boundaries seriously:
- Public ordering is allowed, but scoped to valid table and restaurant combinations.
- Staff routes enforce authentication and ownership checks.
- Price, item validity, and item availability are always verified server-side.
- Translation and management actions are protected by restaurant-level access checks.
- Payment routes expose health/status so the app can degrade gracefully if payments are unavailable.
Result
Eazmenu gives restaurants a practical digital ordering stack that works at table level, supports multilingual menus, and keeps staff in sync in real time.
Operationally, this replaces paper-menu bottlenecks with a faster loop:
- Customer scans and orders.
- Kitchen and staff see updates immediately.
- Manager controls menu, translations, and branding from one dashboard.
Why this matters
The system is designed to be useful on day one for a single location, while still clean enough to scale to more restaurants and more features without rewriting core contracts. The shared schema and type package is a big part of that: customer, admin, and server evolve together with fewer integration bugs.