Restaurant Platform

Why two sides

A restaurant app usually means a menu with a cart, or a booking form. Neither runs a restaurant.

The gap is that the venue's actual operation — which tables exist, who's working tonight, what sold last week, where the money goes — lives somewhere else entirely, usually on paper or in the owner's head. So the app takes orders while the business is still run by hand.

This was built as one product with three faces: what the diner sees on their phone, what staff work off on a tablet, and what the owner runs the business from in a browser.

Setup is the product

Every restaurant is a different shape, so none of it is hardcoded. A venue draws its own rooms, places its own tables, and says how many people each one seats. The layout renders with seat markers around every table at its real capacity.

From then on that layout is the interface, not a picture of one. A booking takes a table rather than a slot in a list. Staff tap a table on the plan and its ticket opens. Reporting comes back as covers per table and revenue per room.

The menu is structured the same way — into the courses the venue actually serves, which it can add, rename and remove. A course is not a filter on a screen: it is how the kitchen ticket groups itself, how the diner browses, and how the analytics rank best and worst, so a dessert is only ever compared against other desserts. Dishes carry up to ten photos each and can be switched off for the night without losing their history.

Booking windows the venue writes itself

A kitchen can seat a lunch sitting at 12:30 and another at 14:00, but not one at 13:15 in between. Fixed half-hour intervals force restaurants to accept bookings they cannot cover, so here the windows are arbitrary ranges the venue types in — 09:30-10:30, 10:30-11:45, 12:30-01:30, 04:00-06:00.

Those same slots drive takeaway collection times. One configuration, two products.

Nothing is auto-confirmed. The request lands on a specific table, and the restaurant sees the guest, the date, the time, the table number and its seat count — plus a mini floor-plan card showing which table that actually is — then accepts or declines. The diner is told it is a request: you will be notified when your reservation has been accepted.

On the service side, a reserved table shows the window it is taken for right on the plan, so anyone can see table two is gone at noon and free at three.

What the diner gets

Discovery with ratings and a nearby list filtered by what is actually open, a photographed menu, and table booking against those real windows.

Takeaway carries per-item modifiers, a special-comment box and a proper breakdown — subtotal, tax and fees, total — paid by card in the app before leaving. Then the part most to-go flows skip: turn-by-turn navigation to the door over a drawn route, with an arrival time measured against the collection window that was chosen, so you know before setting off whether you will make it.

Sitting at the table, a diner can order more from their phone, pay in the app, and watch a points bar climb toward a reward. Points accrue on dining in and ordering to go alike.

Order state updates live rather than on refresh — Realtime Database for the moving parts, Firestore for the records.

Running it as a business, from a browser

Knowing you took $48k tells an owner nothing they can change on Monday. Knowing eleven people ordered the fondant all month tells them exactly what to take off the card.

So the web panel reports per course rather than per receipt: revenue by period at day, month and year, alongside the best and worst seller in plates, desserts and drinks separately.

Staff get sub-accounts issued in seconds with a username and password, each scoped to the job — a waiter takes orders and marks them served; only the owner sees the wallet and moves money out. Nobody shares the owner's credentials across a room full of tablets.

And the money actually arrives. Diners pay by card, the balance accrues in a wallet against a transaction log naming who paid for what, and a withdrawal lands in the restaurant's own bank account within two or three working hours — not on a fortnightly settlement cycle.

Four surfaces on one contract: UI design, a native iOS app, a native Android app and a web admin panel, over Firebase. The Android build alone is 124 source files, 14,114 lines, 92 layouts and 45 screens. The design came from a designer on my team — I led the delivery; I didn't draw the screens. Built and published to both app stores.