One Menu, Ten Branches, Ten Different Price Lists

A ten-branch koshari chain doesn't sell grilled chicken at the same price in a mall food court and on a side street in Imbaba. Rent is different, delivery mix is different, and whoever set the menu knows it. The awkward part used to be technical: if every branch is really its own restaurant record, keeping "Grilled Chicken Half" in sync across ten menus every time a description or photo changes means editing it ten times, or trusting some kind of sync script to do it for you.

menu-MENA's catalog overlay is built around avoiding that trade-off. There's one shared base menu underneath every branch, and each branch stores only the parts that are actually different about it.

One catalog, read from a file, not copied into a database

The base menu is a 1,100+ item catalog covering Egyptian, Levantine, grill, cafe, and dessert categories, stored locally in the codebase (src/data/menu-catalog) rather than written into Firestore for every restaurant that uses it. Categories, items, and modifier groups load from that file at request time, with their IDs stamped catalog-cat-, catalog-item-, and catalog-mg- so the system can always tell a catalog dish from something a restaurant typed in itself.

Because the catalog lives in a file instead of a database row per restaurant, a thousand restaurants on the same catalog collection don't cost a thousand copies of "Koshari Special" in Firestore. They cost nothing, until someone edits one.

Editing a price writes one document, not a new menu

Say Maadi and Zamalek both sell "Grilled Chicken Half" from the same catalog at the same starting price. Open the Menu Editor on the Zamalek branch, change that item's price, and menu-MENA writes exactly one Firestore document: an override keyed to that same catalog-item- ID, sitting under Zamalek's own items collection. Nothing gets written anywhere for Maadi.

When either branch's public page loads, the merge logic in catalog-overlay.ts starts from the catalog's price and lays that branch's own override on top of it, if one exists. Zamalek reads its bumped price. Maadi reads the catalog price, because Maadi has no override to apply. Each branch is a separate tenant record with its own categories, items, and settings collections, so there's no shared document for the two branches to fight over.

The same mechanism covers more than price. Marking an item sold out, hiding it with a soft delete, or swapping its description all work as branch-scoped overrides on top of the same base. A seasonal juice can run out at the airport branch and still show as available downtown, because "sold out" gets written to one branch's collection, not to a flag on the dish itself.

Ten branches, still one menu to think about

Multi-branch restaurant management covers how branches share an owner account and billing while running as separate storefronts. What the overlay adds is the pricing half of that story: adding a branch doesn't mean re-typing 1,100 items and their prices. The "Add a branch" dialog asks for a branch name, a slug, and an optional "Copy menu from" source, then the new branch reads from the same shared catalog its siblings do. From there, only the prices you actually change get written anywhere.

What push update does and doesn't touch

Every branch card in the dashboard has a "Push update…" button that copies categories, items, theme, restaurant info, or the promo bar from one branch to a list of target branches, with a plain warning first: "This overwrites the selected sections on the targets. Existing items in those sections will be replaced."

It's worth knowing exactly what "items" means there. Push skips anything with a catalog-prefixed ID, on both the source it reads from and the destination it clears before writing. A chain-wide push never touches the price you set on a catalog dish at any branch. It only moves items a restaurant typed in from scratch. If a supplier raises the price of chicken and you need to bump ten branches at once, push won't do that part for you: you still edit the price per branch, once each, which is ten small edits rather than ten menu rebuilds. Opening a second branch walks through the clone side of that same trade-off.

What ten branches actually cost

The catalog overlay keeps the data side cheap. The branch add-on pricing is the other half of that. The first branch runs 90 EGP a month or 1,000 EGP a year. Every branch after that is half price: 45 EGP a month or 500 EGP a year, on whichever billing cycle the account is on. Ten branches means one base price plus nine add-ons, not ten separate subscriptions to track.

Ten different price lists off one menu is what happens when the dish you're pricing and the base item it's based on are stored as two separate things from the start. Change one branch's price and you've written one document. The other nine keep reading the same koshari at the same price they always did.