eMenu

eMenu is a digital menu platform for restaurants and hospitality venues in the Saudi market. I founded it and built it.

The problem it solves

Most “digital menus” are a PDF behind a QR code. That solves printing costs and nothing else. The menu is still a static artifact: changing a price means regenerating a file, an item that ran out stays on the menu all evening, and a venue with several branches maintains several versions that drift apart within a week.

A menu is actually a live view of what a kitchen can serve right now. Once you treat it that way, the requirements change completely.

What makes it hard

• Multi-tenant with a strong branding requirement. A restaurant’s menu is part of its identity, so tenants need real visual control — theming, layout, imagery — without each becoming a bespoke deployment. The tension between “every tenant looks different” and “there is one codebase to maintain” is the central design problem.
• Multi-branch, multi-language. A group operates several venues that share most of a menu but not all of it, in Arabic and English, where item names, descriptions, and allergen information all have to stay in sync per locale. The data model has to represent “shared item, branch-level override” natively or the whole thing collapses into copy-paste.
• The guest side is a performance problem, not a feature problem. It loads on a phone, on venue wifi or mobile data, while someone is waiting to order. Every kilobyte is a real cost. This is where I learned most of what I now apply to performance budgets by default.
• Availability changes constantly. Marking an item unavailable has to reach every open guest session quickly, or the menu is lying to customers in real time.

How it’s built

Same architectural stance as the rest of my platform work: tenancy and identity settled first, a modular core with real boundaries, one deployable unit. Menu content, theming, and availability are separate modules with separate lifecycles, because they change at completely different rates — theming almost never, availability many times a day.

Where this is relevant to you

The pattern generalizes to any product where tenants need to look distinct while running on one system: multi-brand catalogs, franchise operations, white-labelled portals. The question is always the same one — how much variation do you push into configuration before you have accidentally built a bespoke deployment per customer.