MoP Restaurant
Showcase, reservations and dining room in a single program.
Three tools for a single location
A restaurant usually has a website made by someone, reservations on an external service, and orders on paper or on a POS system that doesn't talk to either. The online menu is old, the reservation arrives by email, and there is shouting in the kitchen.
The question was whether a single program, small and fast, could do all three things together: the showcase for those looking for a venue, reservations for those who want a table, the floor for those who work.
Three things, one single base
The tiered showcase
An illustration of the building serves as the home page: you descend through floors toward menus, reservations, about us, gallery, and contacts. Each page arrives already written by the server, in seven languages, and lights up in the browser immediately after.
Reservations
The public form asks for the service shift, the number of covers, and notes — allergies, occasions, table preferences. The request ends up in the manager panel, which confirms it, accommodates it, or marks it as not presented.
The dining room in real time
The waiter composes the order from the phone; each line goes to the right station, kitchen or bar, and appears on their screen at the same instant. When it is ready, it returns to the waiter; when it is served, it disappears. No manual updates.
One process, three screens
Workstations do not query each other: each order publishes an event on an internal program channel, and each screen listens only to the events that concern it — the kitchen for dishes, the bar for drinks, the waiter for everything. The browser keeps a single connection open and receives, instead of asking.
Every line of the order captures the name, station, and price of the dish at the moment it is ordered: the manager can change the menu halfway through service without touching what is already in the kitchen.
Open to those who want to try, closed to those who want to break things
A staff area open to the world is an invitation. The storefront is; the dining room has rules.
Log in with a mop.dev account
Waiter, kitchen, bar and manager request access: the visitor enters with their own mop.dev account and every action is linked to the person who performed it.
Daily quotes
Each account has a limited number of orders, status changes, menu modifications, and shifts per day; the public booking module has a limit per address. Beyond that, a polite message and nothing else.
Resets every night, by itself
An internal activity within the program empties orders, reservations, and shifts and resets the starting menu. It works only on the restaurant's database and refuses to start if the database name is not correct.
Security rules calculated at startup
The content policy that the browser applies is calculated by the server at every startup based on the actual published files: a new version cannot accidentally block its own code.
No edge-cached pages
Files with the fingerprint in the name are kept for a year; the page itself never. Whoever arrives sees the current state, not yesterday's.
Out of search engines
It's a demo, not a restaurant: the pages ask search engines not to index them, so no one books a table that doesn't exist.
Small by design
A single program serves the storefront, the API, and the dining room screens: fewer parts, fewer things that break at night.
One process, one database
Showcase, reservations, dining room and manager panel live in the same executable, with a dedicated database: it is installed, it is started, and everything is there.
Server-side rendering
Every page arrives already written from the server and then renders in the browser: it can be read even with a slow network, and a shared link shows the correct preview.
Events, not queries
The dining room screens receive updates over a connection that stays open: no reloading, no repeated requests every few seconds.
Test against a real database
The tests for the reserved area run on a real database and refuse to start without it: a denied access, an exceeded quota, a nightly reset are actually tested, not simulated.
Seven languages
Arabic, German, English, Spanish, French, Italian and Chinese: the flag on the roof changes them all, menu included.
Automatic delivery
Every version goes through formatting, static checks, and tests, then is put online with an atomic swap and a health check: if it doesn't respond, the previous version rolls back automatically.
What can be counted
What it is, what it is not yet
It's a showcase: the menu and photos are from a restaurant that doesn't exist, and the gallery is waiting for real images. There are no payments, no table bills, nor connection to a cash register.
The dining room is a demo with quotas and nightly resets; in an installation for a real venue, the data remains and staff access belongs to the restaurant.
The next step is already designed
Confirmed bookings with reminders and deposits, table bills from orders already entered with payment via phone, loyalty cards for returning customers and a single manager for those with multiple locations.
None of these is a promise: what a restaurateur really asks for is built, with a dedicated quote.
Look at the storefront, or bring it to your restaurants
The showcase is online and can be visited without registering; with a mop.dev account you can also test the dining area. If you work with those who cook and serve, it can be released under your brand.