Systems I build
Digital menu system
A digital menu system treats the menu as a live view of what the kitchen can serve right now, rather than as a file regenerated whenever a price changes. That difference is the whole product: an item marked unavailable has to reach every open guest session quickly, a group with several branches needs shared items with branch-level overrides, and each venue needs real control over how its menu looks without becoming a separate deployment. The guest side is a performance problem before it is a feature problem — it loads on a phone, on venue wifi, while someone is waiting to order. I founded and built eMenu, a digital menu platform for restaurants and hospitality venues in the Saudi market, so the trade-offs below are ones I have had to settle in production.
A menu that is a live system rather than a PDF behind a QR code — priced, branded, multi-branch, bilingual, and correct the moment an item runs out.
Who needs a digital menu system?
A digital menu system is for a venue or a group whose menu changes often enough that maintaining it as a file has become a job. If your menu changes twice a year and you have one location, a well-made PDF is a reasonable answer and I will say so. The case for a system starts when the menu is operational data rather than a printed artifact.
That is usually true when:
- Items run out during service, and the menu keeps offering them until someone regenerates a file.
- Several branches share most of a menu but not all of it, and the versions have already drifted apart.
- The menu exists in Arabic and English, and the two are maintained by different people at different times.
- Each venue in a group needs to look like itself rather than like the platform.
- Prices change often enough that the delay between deciding and publishing is a real cost.
I work with restaurant groups, hospitality operators, and the platforms that serve them, mostly across the Gulf and the wider MENA region, in Arabic and English.
What does a digital menu system include?
A digital menu build covers the full lifecycle rather than the build phase alone: business analysis and product planning, architecture and system design, development and delivery, cloud deployment and scaling, and App Store releases where there is a mobile surface. On a menu platform specifically, the substance is:
- The menu model — categories, items, modifiers, and prices, with per-branch overrides as a first-class concept rather than a later addition.
- Availability as its own module, with its own update path, because it changes many times a service while descriptions change a few times a year.
- Per-tenant branding — theming, layout, and imagery under real tenant control, bounded so that variation stays configuration rather than becoming a bespoke deployment per customer.
- Bilingual content with an explicit answer for a missing translation, and a layout that reverses structurally for Arabic rather than by stylesheet — the architecture side of that is covered under SaaS platform development.
- The guest experience treated as a performance budget — it loads on a phone, on venue wifi, while someone waits to order, so image weight and payload size are requirements rather than afterthoughts.
- The admin interface the venue actually operates, designed for someone marking items out mid-service on a phone, not for a desk.
- Integrations with a POS or stock system where one exists, each behind a single boundary, so the same truth is not maintained in two places.
- Deployment, environments, and the observability needed to answer why a menu was slow in one venue on one evening.
How does a digital menu build run?
A digital menu build starts with the model, not the screens. What a branch is, what an override is, and what a translation is get settled and written down before any interface exists, because all three are expensive to change once real menus are in the system — each one touches every piece of content already entered.
Then the lifecycle in order:
- Business analysis and product planning — how many branches, which languages, who edits the menu and on what device, and whether a POS is already holding some of this.
- Architecture and system design — the tenancy model, the override model, and the separation between content, branding, and availability.
- Development and delivery — a modular monolith by default: real boundaries between those modules, one thing to deploy.
- Cloud deployment and scaling — environments and the traces that make a slow guest page answerable rather than debatable.
- App Store releases where there is a mobile surface.
The rule that decides the hard calls on this product is the one from the branding question above: variation belongs in configuration until the point where it would cost engineering time per tenant. That line is a business decision as much as a technical one, which is why it gets argued out with you rather than assumed by the code.
Questions about this work
What is the difference between a QR code menu and a digital menu system?
A QR code menu is a file — usually a PDF — reached by scanning. It solves printing cost and nothing else. The menu is still a static artifact: changing a price means regenerating and re-uploading the file, an item that ran out at seven o'clock stays on the menu all evening, and a venue with several branches keeps several versions that drift apart within a week. A digital menu system stores the menu as data instead: prices, availability, translations, and branding are fields that can change independently, and the guest page is rendered from them on request. The test is simple — if marking an item unavailable requires anyone to open a design tool, it is a file, not a system.
How quickly does an item marked unavailable disappear for guests?
Fast enough that the menu is not lying to a customer who is deciding right now, which is a stricter requirement than it first sounds. Guests sit with a menu open for several minutes, so the page cannot simply be correct at load time and stale thereafter. That pushes availability into its own module with its own update path, separate from menu content, because the two change at completely different rates — a description is edited a few times a year, availability many times a service. The design decision worth making explicitly is what a guest sees at the moment of change: an item that vanishes mid-read is confusing, and marking it unavailable in place is usually the better behaviour.
How does a group with several branches share one menu without duplicating it?
By modelling "shared item with branch-level override" natively, in the data model, from the beginning. Branches genuinely share most of a menu and genuinely differ in parts of it — a price that varies by location, an item one kitchen cannot produce, a seasonal addition at one venue. If the model only knows about per-branch menus, the shared parts get copied, and copies drift: within a week the same dish has two descriptions and two prices. If it only knows about one global menu, every local difference becomes a workaround. The override has to be a first-class concept, and retrofitting it later means migrating every menu the platform holds.
Can each restaurant control how its own menu looks?
Yes, and this is the central design tension in the product rather than a styling detail. A menu is part of a restaurant's identity, so tenants need real visual control — theming, layout, imagery. But every degree of freedom granted is a combination that has to keep working on every screen size, in both reading directions, at whatever image weight the tenant uploads. The question I settle early with a client is how much variation goes into configuration before you have accidentally built a bespoke deployment per customer, because past that line each new tenant costs engineering time rather than onboarding time.
How are bilingual menu items kept in sync between Arabic and English?
By making each translatable field a per-language value on the item itself, and by deciding up front what happens when one side is empty. Item names, descriptions, and allergen information each need a value per language, and someone adding a dish at four in the afternoon will fill in one language and intend to come back to the other. So the model has to answer what a guest sees in the meantime: falling back silently to the other language is how a menu ends up half-Arabic in front of a customer, and hiding the item entirely means the kitchen is selling something the menu does not list. Whichever you choose, the admin interface has to make the gap visible to the person who created it. Whether a second language changes the architecture underneath is a broader question, and it belongs to SaaS platform development rather than to the menu.
Does the menu need to connect to our POS or ordering system?
Only if you want availability and pricing to stop being maintained twice. A digital menu works perfectly well standalone, with staff marking items in and out through an admin interface — many venues run exactly that way and it is the cheaper starting point. The case for integration is when the same information already lives in a point-of-sale or stock system, because two systems holding the same truth is two systems that will disagree by Friday. When that integration exists it sits behind one boundary with a shared internal representation, so changing POS vendor later is implementing an interface rather than rewriting the menu.
Digital menu system — tell me what you're working with.
Start a conversation