Abu JbaraAbu Jbara

Sole engineer: product design, the FastAPI backend and data model, the AI waiter and its guards, the real-time layer, and the bilingual guest and staff apps.

At a busy restaurant, guests wait to order, call for the bill and repeat requests, and staff juggle tables from memory. Off-the-shelf QR menus only show a list of dishes, and a chatbot that takes orders is risky: a language model can invent dishes, prices or confirmations, and most cannot understand how people in Amman actually talk.

Every table has its own QR code. Scanning it opens a guest app tied to that table, with no sign-up: a photo menu with real prices, a basket that is re-priced on the server and confirmed before it reaches the kitchen, live order tracking (received, in the kitchen, ready), one-tap table services (call staff, tissues, clean table, bill, complaints) and changes to a sent order until it is ready.

The AI waiter understands Jordanian dialect, standard Arabic, English and a mix of them. It answers from the restaurant's own menu, recommends, adds dishes with notes such as "one tea without sugar", summarises the order with exact prices and sends it only after the guest confirms. Staff run the room from a live floor map of the real layout, an incoming-orders panel, a service queue, per-table visits with the running bill, menu management, printable QR codes and per-purpose AI settings.

A Next.js 16 guest and staff app talks to a FastAPI backend on async SQLAlchemy and PostgreSQL with pgvector. The waiter uses Gemini tool calling, and every tool call goes through server-side checks. Menu search is hybrid, combining dish-name matching with vector embeddings, and falls back to name matching on its own when the embedding provider is unavailable. Order, status and service events are written to a transactional outbox and pushed to guests and staff over WebSockets. AI provider, model and key are set per purpose (chat, menu search, dictation, live voice), with keys encrypted at rest.

Letting a language model take real orders without trusting it: a dish can only be ordered after it was shown to the guest, the table and guest always come from the QR session rather than the conversation, the order needs an explicit confirmation in a later message, and prices are recomputed at submit. Understanding dialect requests like "شاي بدون سكر" and keeping each note on the right line. Keeping the floor map, the kitchen and every guest's phone in sync in real time.

Guards in code, not in the prompt, so a clever message cannot place an unconfirmed order or change a price. A transactional outbox so a live update is never lost or sent for an order that did not commit. Graceful degradation everywhere: semantic search falls back to name matching and the guest can always order by tapping. Production refuses to start with weak secrets.

In a recorded run on Gemini 3.1 Flash Lite, a guest asked about hummus in Jordanian Arabic, ordered two plates of hummus with pine nuts, six falafel and two teas (one without sugar), declined a suggested side, received a priced summary and confirmed by text. Order AJ-107 reached the kitchen at 15.00 JOD with both tea notes attached, and every price in the chat matched the menu exactly. The order appeared on the staff floor map about two seconds after confirmation, and as staff pressed Start preparing and Ready, the guest's tracker followed live. Waiter replies arrived in roughly 1 to 4 seconds, and the automated suite passed 257 tests.