A restaurant ordering system for small chains, scoped

A single restaurant can run on a tablet and a notebook. A chain of four cannot, and the reason is not volume. It is that four branches produce four versions of the truth about what is on the menu, what it costs, and what was sold, and reconciling those by phone at the end of the week is the actual job the software is being hired to remove.

This is a note about what to specify before anyone talks about screens. The customer facing ordering flow is the easy part and the part every vendor demos. The three things below are what separate a system a small chain can run from one it quietly stops using.

The receipt is a compliance artefact, not a printout

In Egypt this is the constraint that reshapes the whole build, and it is routinely discovered late. The Egyptian Tax Authority's electronic receipt system is not a reporting layer you add afterwards. Its receipt issuance documentation sets out requirements that reach directly into how the ordering system has to be designed.

Three of them matter at architecture time. Receipts must be submitted within an allowed window of 24 hours. The point of sale device has to be registered and linked to the issuer before a receipt is issued, and a device that has been retired causes the document to be rejected regardless of how it was submitted. The issuer also has to carry the B2C designation to be permitted to issue receipts at all.

Read those together and a design falls out. Device identity is not an afterthought you bolt on at deployment; it is part of the data model from day one, because a receipt is tied to a registered device rather than to a branch or a user. And because submission has a deadline measured in hours rather than seconds, the system needs a queue with retry, not a synchronous call that fails the order when the tax endpoint is slow.

One menu, four branches, and the price that differs

The second thing that breaks is menu management. Every chain believes it has one menu. Every chain has one menu plus exceptions: a branch that does not do breakfast, a delivery price that is higher than dine in, an item that is seasonal in one location, a combo that exists only on Fridays.

If the data model treats the menu as a single global list, those exceptions get handled by staff overriding prices at the till, which destroys the reporting you built the system for. If it treats every branch as fully independent, nobody can change a price once and have it apply everywhere, which was the original complaint. The workable model is a central catalogue with per branch overrides that are explicit and auditable, so a wrong price is a visible override rather than a mystery.

The offline case decides the architecture

Ask what happens when connectivity fails during service. This single question separates realistic briefs from optimistic ones, because the honest answer for most small chains is that service continues and the system has to catch up afterwards.

That has consequences. Order identifiers have to be generated locally without collisions, which means no relying on a central database to hand out sequential numbers. Anything time sensitive has to record when it happened rather than when it synced. And the compliance queue above is the same mechanism, which is convenient: build the queue once and it serves both the tax submission and the offline case.

The alternative, a system that requires connectivity to take an order, is genuinely simpler to build and is the right choice for some sites. It is only the wrong choice if nobody was asked.

What to build first

• Central catalogue with explicit per branch overrides, before any customer facing screen
• Device registry, because the receipt rules depend on it
• A submission queue with retry and a visible failure state somebody is responsible for
• Local order identifiers that survive an outage
• One report that answers the question the owner currently asks by phone

That last one is the acceptance test. If the system does not remove the weekly reconciliation call, it has added work rather than replaced it, which is the failure mode we described in when a stock spreadsheet starts costing more than it saves.

Build, buy, or postpone

Off the shelf restaurant platforms exist and for a four branch chain they are frequently the right answer, particularly where they already handle the local tax integration. Custom becomes defensible when the menu logic or the delivery model is genuinely unusual, or when integration with something you already run matters more than the ordering screen itself. That is the same build versus buy calculation we worked through for a different system in how much a custom CRM costs.

If the current state is a spreadsheet per branch, the migration path matters more than the destination, and we set out how to stage that in Excel to web app migration. Whichever route you take, scope it before anyone estimates it, for the reasons in how to scope a software project before anyone writes code.

One adjacent point, since a chain investing in ordering usually has a discovery problem too. Being findable locally is a separate discipline from the ordering stack, and our colleagues at KF Agency wrote the practical version for Egyptian restaurants and cafes in a guide to local SEO for restaurants and cafes in Egypt. It is written in Arabic.

Honest limits

We have deliberately not given you a price or a timeline here. Both depend on whether the tax integration is done by you or inherited from a certified provider, and that single decision moves the number more than anything else in the specification. Anyone quoting a restaurant ordering system without first asking which of those applies is quoting a different project.

The compliance detail above is also specific to Egypt and specific to the date of writing. Tax authority requirements change, the documentation is the authority rather than this note, and a system built to a summary of the rules rather than the rules themselves is a system with an expiry date. Read the primary source, and re-read it before you go live.