# A restaurant management system (restro.emgeelabs.in)

> QR-code ordering at the table, a live kitchen queue, and the owner screens behind them. A restaurant management system designed and built by EmGee Labs, in Angular and Firebase.

A diner scans the QR code on their table, browses the menu and places an order. The
kitchen sees it arrive on a live queue and moves it through preparing to completed, and
the diner watches the same order move. No app to install, no account, and no login anywhere in the diner's path.

Staff sign in with Google. A manager gets the kitchen queue; an owner gets the menu, the
tables and their QR codes, the order history, order editing, staff management,
notifications and the restaurant profile.

This subdomain is one page about that system. There is no product name on it: the name
is not settled. It is not a hosted service you can sign up for, there is no pricing and
no account, and this page sells nothing - it is a description of a system that was
designed and built, with three real screenshots of it running.

Every page on this subdomain is static HTML and needs no JavaScript to read.

## What it does

Six capabilities, in the order the work happens in. Every one is a screen or a behaviour the application has.

- Scan the table, and the menu opens: each table has its own QR code, and it opens that table's menu directly. The table number is already known, so nothing has to be typed and nobody has to be flagged down.
- Order without an account: browse by category, filter to vegetarian, add items and adjust quantities. There is no app to install, no account to create and no login anywhere in the diner's path.
- A checkout that asks for a phone number and little else: the cart shows every line, its quantity and the running total. A phone number is required and a name is optional - and a phone number that has ordered before fills its own name in.
- The kitchen sees the order as it is placed: orders arrive on a live queue as cards, filtered to pending, preparing or all of them, and are moved through those states as the kitchen works.
- The diner watches the same order move: placing an order returns a link that tracks it from pending to preparing to completed, updating on its own rather than on a refresh.
- And can find it again from anywhere: an order number and the phone number that placed it are enough to open an order again, on another phone, with nothing to sign in to.

## What the owner gets

- Menu management: add, edit and remove items; set price, description, category and calories; mark an item vegetarian, popular, out of stock or inactive without deleting it.
- Tables and their QR codes: the dining tables are kept on the restaurant's own record, and the QR code for a table is generated in the app and downloaded to be printed.
- Order history, searchable: every order the restaurant has taken, searchable and filterable, each one openable in full.
- Editing an order after it is placed: the wrong item, a change at the table, a cancellation - an order stays editable rather than being something only the kitchen can fix.
- Staff and access: a manager is invited by their Gmail address, signs in with Google, and gets the kitchen queue and nothing else. The owner adds and removes them from inside the app.
- Push to the kitchen, and a way to test it: a new order raises a browser push notification on the kitchen's device, and the notifications screen sends a test alert so the device can be proved registered.

## Who can do what

Three tiers exist in the code. The fourth is listed because the written specification describes it and the application does not have it.

- Diner (No sign-in at all): the menu, the cart, their own order's status, and looking an order up again. Reached from the table's QR code and nothing else.
- Manager (Signs in with Google): the kitchen queue, and only that. The route guard sends a manager who asks for an owner screen back to the queue.
- Owner (Signs in with Google): every screen for their own restaurant: the menu, the tables and their QR codes, the order history, order editing, staff, notifications and the restaurant's own profile.
- Super admin (Not built): the specification describes a tier that manages restaurants across the whole install. It is not in the code - there is no such role, no guard for it and no screen.

## How it is built

- Angular 21: standalone components, lazily loaded a screen at a time, with route guards deciding who reaches what.
- Firebase Firestore: the database, read through live listeners - which is why the kitchen queue and the diner's order status both move without a refresh.
- Firebase Auth: Google sign-in, and only for staff. It is never in a diner's way.
- Firebase Cloud Messaging: browser push, so a kitchen that is not looking at the screen still learns about an order.
- Firebase Hosting: where it is deployed, with the single-page rewrite that lets a table's QR URL resolve.

## What it is not

Stated because the rest of this file would otherwise imply a finished commercial product. It is a working system with a real screen list.

- There is no payment step: an order is placed and a bill is produced, and money is settled the way the restaurant already settles it. Nothing here takes a card.
- The analytics dashboard is switched off: the screen is built, and its route is disabled in the router until the numbers behind it are real. It is not reachable, so it is not claimed here.
- One restaurant at a time: the data is laid out per restaurant and the app works within one. The cross-restaurant administration tier described in the specification is not built.
- Menu photography is optional and mostly absent: items carry an image if one is uploaded, and the running deployment mostly has none - which is what the screenshots on this page show, because they were not staged.

## Screens on this page

Three real captures of the running application, not mock-ups. The kitchen queue and the owner screens are described rather than shown, because every one of them is behind Google sign-in.

- [diner-table.png](https://restro.emgeelabs.in/shots/diner-table.png): A phone screen showing a table number, the restaurant's name, and two buttons: Browse Menu, and View Active Orders.
- [diner-menu.png](https://restro.emgeelabs.in/shots/diner-menu.png): A phone screen showing a searchable menu: a vegetarian filter, category tabs for starters, mains and drinks, and menu items with prices and an Add button each.
- [diner-cart.png](https://restro.emgeelabs.in/shots/diner-cart.png): A phone screen showing an order of two items with quantity controls, a grand total, and a checkout asking for a phone number and an optional name.

## Also on this subdomain

- [llms-full.txt](https://restro.emgeelabs.in/llms-full.txt): This page inlined as plain text.
- [robots.txt](https://restro.emgeelabs.in/robots.txt): All crawlers allowed.
- [sitemap.xml](https://restro.emgeelabs.in/sitemap.xml): Every page on this subdomain.

## Who built it

- [EmGee Labs](https://emgeelabs.in/): The studio that designed and built this system: what it builds, how the work is bought, and how to reach it.