Unified online ordering and delivery management platforms for Saudi F&B and retail brands.
Nearly every operator who asks us about online ordering is already taking online orders. They are arriving on three or four aggregator tablets on a shelf behind the pass, on a website somebody built two years ago, and on messaging apps. The question is never "should we take online orders" - it is why the tablets have to be re-keyed into the point-of-sale by hand at the busiest hour of the day, why the menu on one channel is a week behind the menu on another, and why nobody can say what a delivered order actually earns after commission.
That is the honest subject of this category: not taking the order, but the distance between where the order lands and where the kitchen and the books live. No purchase closes that distance by itself, and several close it in one channel while widening it in another.
Our interest, stated before the argument rather than after it: Trustangle is an independent advisory firm. We do selection and implementation work, which is a genuine commercial interest in your decision, and you should have that before you read further. Where we hold a partnership or accreditation with a vendor named here, it is published on our partners page rather than implied in the copy. We do not earn a margin on your licence, which is what makes it possible for us to tell you that the ordering module in the point-of-sale you already own may be the right answer.
"Online ordering system" is sold as one thing and is really four, and the overlap is where buyers get hurt.
The direct channel. Your own branded ordering - web and app - where you own the customer record, the menu, the pricing and the margin, and where you also own the acquisition problem. Nobody arrives at it by accident.
Aggregator and marketplace integration. The third-party demand channels. In Saudi Arabia the ones operators ask about by name are HungerStation [source: hungerstation.com], Jahez [source: jahez.net] and Keeta [source: keeta.com]. Each publishes its own partner and integration route, and what matters commercially is not that you are "on" them but whether their orders arrive in your systems as data or as a tablet somebody retypes.
Channel and menu management. The layer that keeps one menu, one price list, one modifier set and one availability state consistent across every channel, and that can suspend an item everywhere at once when it runs out. This is the layer most often missing, and its absence is what produces the refunds.
Order injection and kitchen routing. Getting the order into the point-of-sale and onto the right screen or printer without a human, with the correct routing between prep stations, and with the order state flowing back out to the customer. This is the layer that decides whether the system saves labour or adds it.
Two things make the overlap worse than it looks. Serious vendors in each of these four have extended into the neighbouring ones, so a menu manager will show you a storefront and a point-of-sale will show you aggregator integration - each competently enough to demonstrate. And modern point-of-sale platforms include a version of most of it, which is frequently sufficient and occasionally nowhere near. Establishing which is true for you is worth more than any feature grid, and it is a question about your channel mix and your order volume rather than about the software.
You do not need all of these. Two or three together usually mean the investment repays itself, and which two point at which layer you are actually buying.
When you do not need this yet. A single site with one aggregator and a manageable volume does not need a platform; it needs the aggregator's own integration turned on. And if the underlying problem is that your item master is wrong - modifiers that do not match the kitchen, prices that differ by branch for no reason, items with no recipe behind them - a platform will industrialise that inconsistency across four channels instead of one. That is not a reason to do nothing; it is a reason to spend a few weeks on menu data first, after which the software decision is both cheaper and much easier.
Every evaluation starts from your operation rather than a feature grid, for a practical reason: at this scale the serious platforms all do the headline things, so a headline comparison always ends in a tie. What separates them is behaviour at the edges your operation actually lives on.
What share of orders is direct versus aggregator today, and what you want that to be. How many branches, and do they differ in menu or price. What is your point-of-sale, and what does its vendor publish about integration. Who maintains the menu now. What happens at peak. What does a delivered order cost you, all in - and if nobody knows, that is the first deliverable, before any shortlist.
We implement Lynnc in this category. One named platform is the honest picture of what we deliver here today rather than a shortlist dressed up as a market survey, and it is the reason this page spends its length on the category rather than on a product grid. What that platform does is described on its own page, in its vendor's own terms; nothing is claimed for it here.
Where the fit is not right, we say so and point at the neighbouring category: most operators whose ordering problem is really a point-of-sale problem are better served from point of sale systems, where the ordering module of a platform you may already own is evaluated alongside the rest of it.
Compared here are the layers of the category, not products against each other - a product comparison would be a vendor capability claim, and those are not made on this page.
| Layer | Decides | Bought separately when |
|---|---|---|
| Direct channel | Margin and customer ownership | You have demand you are currently renting |
| Aggregator integration | Reach | Orders arrive as tablets, not data |
| Menu & channel management | Consistency | Menus disagree across channels |
| Order injection & routing | Labour at peak | Orders are re-keyed by hand |
We do not publish price ranges for this category, because the numbers that decide the bill are yours and not the vendor's. What we can publish are the drivers, so you can build the question yourself and recognise a quote that has ignored one: per-branch versus per-order versus per-channel licensing and which of those your growth multiplies; the aggregator commission you are already paying, which is usually larger than the software line and is the number the business case turns on; point-of-sale integration work, including any middleware and any vendor charge for their side of it; menu data preparation, which is labour and is nearly always underestimated; the direct channel's acquisition cost, without which the direct channel is a website nobody visits; and the run cost - who maintains the menu, and whether that is a job or an afterthought.
The three-year total is what matters, not the licence, and the largest line in it is frequently not software at all.
Structural only. Institutions and obligations by function; confirm current detail with each authority.
E-invoicing. Sales through any channel are still sales. The Zakat, Tax and Customs Authority operates Saudi Arabia's e-invoicing regime and its Fatoora platform, and invoices generated for online orders fall within it like any other. What matters when selecting is whether the ordering platform issues documents itself or hands off to a point-of-sale that is already compliant - and if it issues them, whether it does so through a solution ZATCA recognises. [source: zatca.gov.sa]
Arabic. ZATCA's e-invoicing requirements govern the language of a tax invoice. Beyond the invoice, a customer-facing ordering channel in this market that is English-only is a commercial decision before it is a technical one; the practical questions for selection are whether the platform supports Arabic content and right-to-left layout in the storefront, and whether menu data can carry both languages. [source: zatca.gov.sa]
Personal data. Direct ordering means you hold customer identity, address, location and order history, and marketing to that list is processing personal data. The Personal Data Protection Law and its implementing regulations, with the Saudi Data & AI Authority as competent authority, govern that - consent for marketing and data-transfer arrangements are the two questions that most often surface in these projects. [source: sdaia.gov.sa]
Selling online. The Ministry of Commerce administers the e-commerce framework and the Maroof platform for authenticating online stores; operators launching a direct channel should confirm where their store stands with both. [source: mc.gov.sa; maroof.sa]
Payments. Card and wallet acceptance on a direct channel sits under the Saudi Central Bank's supervision of payment services, and the practical selection question is which payment service providers the platform already supports in this market. [source: sama.gov.sa]
Addressing. Delivery accuracy in this market rests on the national addressing scheme more than on map pins. Our guide to national address registration covers what that means for a delivery operation.
A short discovery that establishes your channel mix, your point-of-sale, your menu structure and what a delivered order actually costs you. A written shortlist with the reasoning visible, including the case for changing nothing. Scripted demonstrations against your menu and your peak, not the vendor's. A commercial review of the whole three-year picture. Then implementation: menu data first, integrations second, a single-branch pilot through a real peak, and only then a rollout. Training is aimed at whoever will own the menu after we leave, because that is the role that decides whether this holds.
We do not publish a number, because the honest answer is a range wide enough to be useless without your details. What sets it: how many branches, how clean the menu data is, whether the point-of-sale integration is a published one or bespoke, how many channels go live at once, and whether a direct channel is in scope. Menu preparation and the pilot peak are the two stages most often underestimated. We give a dated plan after discovery, not before.
Licence plus integration plus menu preparation plus the direct channel's acquisition cost plus the internal time to maintain it - and, dominating all of them for most operators, the aggregator commission on the orders flowing through. Section 5 lists the drivers. Any quote that prices only the first of those is not a three-year number.
Not as a property of the product - as a property of how it is configured and what it is connected to. The obligations that bite are e-invoicing through ZATCA [zatca.gov.sa], personal data under the PDPL with SDAIA as competent authority [sdaia.gov.sa], the e-commerce framework and Maroof for a direct store [mc.gov.sa; maroof.sa], and payment acceptance under the Saudi Central Bank [sama.gov.sa]. Where a platform is hosted, and whether that is acceptable for your sector, is a question to put to the vendor in writing and to check against current requirements - not one to take from a sales deck or from this page.
We publish the shortlist and the reasoning with every recommendation, including what we rejected and why. If a recommendation arrives without that, it is not independent advice regardless of who wrote it.
Usually, and that is normally the right shape. The ordering layer is one of the few places where adding rather than replacing genuinely works, because the point-of-sale stays the system of record. The question to settle first is which system owns the menu - two systems that both think they do is the most common failure in this category.
This section carries no number, and we would rather say that plainly than publish one we cannot evidence. What we would tell you to demand of any adviser in this category, including us: how many implementations they have actually delivered on your point-of-sale, how many went live on time, how many are still running three years later, and the name of one client who will take your call. Ask for those in a meeting, where they can be checked.
We do not name clients on this page without their written agreement, and we do not publish a logo wall assembled from projects nobody consented to display. References relevant to your segment and your point-of-sale are offered during evaluation, directly and by name.
Case material is shared under the same rule as section 10: relevant, named, and only with the client's agreement. What we will not do is publish an anonymous percentage improvement, because an unattributable number is not evidence.
Testimonials appear here only when a real client has written and approved one. There are none invented in the meantime.
Our partnerships and accreditations are published and maintained on the partners page, which is the single source of truth for them. We do not restate them in body copy, where they go stale silently and where a claim is hardest to check.
Point of sale systems - the adjacent category, and the right starting point if the ordering problem is really a point-of-sale problem. All solutions and platforms - the full catalogue. Independent software comparisons - our published, vendor-neutral comparisons. National address registration - the addressing layer under every delivery promise in this market.
Bring your channel mix, your point-of-sale and one month of order data. Book a decision session - or start with an impartial assessment - and we will tell you, plainly, whether this is a platform decision, a menu-data project, or a configuration you already own and have not switched on. If it is the last of those, we will say so.
