Solutions / Food & beverage
A till is the one piece of software in your business that must not stop — not mid-service, not when the mall Wi-Fi drops. We build restaurant POS for operators in Dubai, Riyadh and Jeddah: offline-first at the terminal, honest about compliance, built around your kitchen.
What we build first — and what we argue about in scoping, because the detail in each is where a POS is either used or worked around.
The screen a server touches four hundred times a shift. Built for muscle memory, not for a demo: common items without hunting, modifiers in the flow of the order, a layout that survives a new starter on day two.
A floor plan matching the room, with covers, seat numbers, course timing and table state at a glance. Transfer a table, move a section at handover, spot who has waited twenty minutes on a main.
Tickets routed by station, so grill, starters and desserts each see only what they own and course firing is controlled. A kitchen display replaces the printer if it handles bump, recall and all-day counts. We keep a printer fallback.
Split by cover, item or percentage. Merge tables that pushed together mid-meal. Take partial payments across several methods on one bill. This is where thin products give up and a queue forms at the till.
The terminal keeps menu, prices, open tables and orders locally, so it sells with no connection. Queued transactions sync on reconnect with a defined conflict rule. We test by pulling the cable during a simulated service, not by reading a datasheet.
Items, variants, modifier groups with rules, combos, day-parting, and the ability to 86 an item on one branch without a developer. Modifier logic is a pricing matrix, not a checkbox.
One menu defined centrally and pushed everywhere, with controlled local overrides for price by location. Head office changes a price once and knows it landed in twelve tills across two countries.
Recipes mapped to ingredients, so a sale depletes stock and theoretical usage meets a physical count. Waste logged with a reason. This can feed business intelligence or analytics instead of a monthly export.
Clock in and out, shift reports, cash-up with a variance you can investigate, and permissions that stop a server voiding their own bill. Every discount and void is attributable to a person and a reason.
In Saudi Arabia, e-invoicing sits under ZATCA — the Zakat, Tax and Customs Authority — through the Fatoora programme. Phase 1, "Generation", has applied since 4 December 2021: structured electronic invoices, mandatory VAT fields, a QR code on simplified invoices. Phase 2, "Integration", began on 1 January 2023 and rolled out in waves by revenue threshold: integration with Fatoora, UBL 2.1 XML (or PDF/A-3 with embedded XML), a cryptographic stamp, a CSID from onboarding your EGS, plus a UUID, an invoice hash and PIH chaining.
For a restaurant the practical point is this: your sales are overwhelmingly business-to-consumer, so they are simplified tax invoices. That means reporting, not clearance. The customer gets the receipt and its QR code immediately, and it is reported within 24 hours — you never wait on a round trip to hand someone their bill.
We will not tell you which wave you are in. Waves and thresholds have advanced repeatedly, and any page naming the "current" threshold is out of date the day it publishes. We confirm your obligations against ZATCA's published guidance per engagement. Inovsion has delivered an ERP-integrated ZATCA e-invoice solution covering EGS onboarding, integration and automated validation.
VAT applies, so the till must produce compliant tax invoices, apply the right treatment per item and keep auditable records. Service charge and municipality fees vary by emirate and venue type, so they are modelled per site, not set globally.
Talabat, Deliveroo, Careem and HungerStation carry a serious share of orders here, and an order on its own tablet is one your kitchen forgets. Integration is scoped per provider: each has its own API, onboarding and commercial terms, access is granted by them and not by us, and we hold no partnership with any of them.
Card terminals, Mada in Saudi Arabia, Apple Pay and cash. The route depends on your acquirer and terminal model, confirmed with your provider in scoping rather than assumed.
A group with sites in Dubai and Riyadh runs two tax regimes, two invoice formats and often two languages. Designing for that early beats retrofitting Saudi compliance later.
We build custom software, and we still think most restaurants should buy a product. If your answers sit in the middle column, buy one.
| Consideration | Off-the-shelf POS | Custom POS |
|---|---|---|
| Time to first service | Days to weeks. | Months of build, test and pilot before anyone sells. |
| Cost shape | Low upfront; per-till fees scale with every site, indefinitely. | Significant upfront; then hosting and support. Can favour large estates. |
| Unusual workflow | You adapt to the product — sometimes healthy, sometimes a daily workaround. | The software adapts to you, including what differentiates you. |
| Multi-country compliance | Depends on the vendor's regional coverage and roadmap. Verify first. | Built for your regimes; ZATCA reporting and UAE VAT as first-class needs. |
| Integrations | Whatever the marketplace offers; anything else is a request and a wait. | Anything with an accessible API, subject to the provider's terms. |
| Your data | In the vendor's platform; leaving is a project. | In your database, ready to feed an ERP or analytics stack. |
| Who fixes it at 9pm | Vendor support, on their SLA and priorities. | Your team or partner, on agreed terms — which means funding support. |
| Best fit | One to roughly ten sites, conventional menu, standard workflow. | Larger, multi-brand or multi-country estates; a genuinely unusual model. |
A middle path often wins: keep a product POS at the till and build the layer around it — the ordering app, loyalty, consolidated reporting. Inovsion has delivered a food ordering app, which sits alongside a POS perfectly well. See our work or food delivery app development.
We sit in your restaurant during a service — the actual floor at peak, not a workshop. We map how orders move, where the queue forms, and your tax position in each country you trade in.
Offline behaviour and sync rules come first, because they constrain everything else. We check compliance against ZATCA's published guidance and UAE VAT rules, and confirm with each aggregator and acquirer what is available.
Short cycles with your operations team seeing real builds. We test offline by killing the connection mid-rehearsal, and validate invoice structure and QR output against the specification. A pilot site runs a real service first.
Rollout branch by branch, with training that fits a shift handover. Then support that reflects the fact a broken till at 9pm on a Friday is not a next-business-day ticket. Compliance changes are scheduled work.
We have delivered an ERP-integrated ZATCA e-invoice solution covering EGS onboarding, integration across a broad range of ERPs, and automated compliance and validation, and we work with clients in Saudi Arabia. Your compliance work is informed by delivery, not by a summary of a regulation.
Our portfolio includes a food ordering app, plus ClueMaster — IoT-enabled software managing escape rooms across multiple locations, the same multi-site, real-time, must-not-fail problem in a different costume — and OneTuch, a logistics platform. See our work.
Yes. We build tills offline-first. The terminal holds a local copy of the menu, prices, open tables and orders, so staff keep selling with no connection. Queued transactions sync and reconcile against the central record when the link returns. In our experience this matters most in F&B: a till that stops selling costs money every minute of a service.
We build POS systems to meet ZATCA e-invoicing requirements under the Fatoora programme. Most restaurant sales are business-to-consumer, so they are simplified tax invoices: the receipt goes out immediately with a QR code and is reported within 24 hours under Phase 2 reporting, not clearance. The EGS is onboarded to obtain a cryptographic stamp identifier, and each invoice carries a UUID, an invoice hash and the previous invoice hash. We confirm requirements against ZATCA published guidance per engagement, because waves and thresholds change.
Clearance applies to standard tax invoices, typically B2B and B2G: ZATCA must clear the invoice before you share it with the buyer. Reporting applies to simplified tax invoices, typically B2C: the buyer gets it immediately and it is reported within 24 hours. Restaurants issue mostly simplified invoices, so reporting is the normal path, though a venue invoicing corporate accounts or running catering may need both.
Integration is scoped per provider. Each aggregator has its own API, onboarding and commercial terms, and access is granted by them, not by us. We hold no partnership with any of them. We confirm what a provider will expose for your accounts before designing, then map their menus and order states onto yours so those orders join the same queue as dine-in.
Cash, card terminals, Mada in Saudi Arabia and Apple Pay are the usual set. The route depends on your acquirer and terminal model, so we confirm it with your provider before scoping. Semi-integrated terminals, where the till sends an amount and the terminal handles the card data, are typically the least painful because they keep card data out of the POS.
If you run a few sites with a conventional menu and no unusual workflow, an off-the-shelf POS is usually cheaper and faster, and we will say so rather than sell you a build. Custom earns its cost when a product will not bend: central menu control with local pricing, recipe costing tied to your supply chain, or reporting that must match an ERP you are not replacing.
It depends on scope, and anyone quoting before scoping is guessing. A single-brand till with menu management, kitchen tickets and compliant invoicing is far smaller than a multi-branch estate with inventory, recipe costing, aggregators and reporting. We scope in phases with a range per phase, so you can run a real service on the till before adding the back office.
Bring us the bit that goes wrong at peak — the queue at the till, the aggregator tablet nobody watches, the food cost nobody trusts. We will tell you honestly whether that needs a custom POS, a product you can buy, or a smaller change.