Your own channel instead of an aggregator: building a premium foodtech ecosystem for a holding of dozens of brands

A dev.family field report: a product that wins back margin and data from aggregators — and the engineering that lets it grow without being rewritten.

Online food delivery in Saudi Arabia is no longer a niche. Grand View Research puts the market at nearly $8B for 2024, growing toward $13B by 2030 (roughly 9% CAGR). Big money, tight competition — and a market where the aggregator makes the rules.

The catch is that the aggregator is an expensive middleman. Commissions from major platforms in the region reach 30–35%, and restaurant guides put the typical Gulf range at 20–30% per order. For a restaurant that isn't just a line item — it's up to a third of the revenue on every delivered dish, taken by someone else. And the money isn't the only thing that leaves: the direct relationship with the customer and the data about them go to the platform, not the brand.

We were approached by a large restaurant holding in the Gulf — around 40 independent brands operating in Saudi Arabia, Kuwait, and the UK, with plans to enter the US. A single brand can span dozens of restaurants in Riyadh alone. Their infrastructure was fragmented to the extreme: every brand had its own apps, its own systems, its own processes. The brief was ambitious — pull this scattered restaurant "universe" into one premium product that doesn't just compete with aggregators but redefines the food-ordering experience.

In retail terms, the idea of your own delivery channel sounds simple: cut out the middleman. But three distinct business reasons sit behind it, and all three mattered to the client.

First, margin. Dropping aggregator commissions puts that 20–35% straight back into the business.

Second, owning the data and the customer. When orders flow through an aggregator, the platform owns purchase history, contacts, and behavior. A first-party channel flips that: the holding gets the direct relationship and its own customer base — the foundation for loyalty, retention, and personalization. The industry calls it ownership over aggregation: first-party orders deliver not only better economics but strategic control over the guest relationship.

Third, the experience. This is where it gets interesting. Simply "cloning the aggregator" isn't enough: if the holding's app feels like every other app, there's no reason for the user to switch. So the channel has to be not just first-party, but noticeably better — premium.

On top of all this sat a scale requirement. From day one the product was designed for an inflow of roughly 160,000–170,000 users (the holding's own base plus aggregator data at launch), for two languages (English and Arabic with RTL), and for multi-currency, multi-region operation.

Here's the paradox the whole project revolved around. Delivery is physically carried out by third parties — someone else's kitchens, someone else's POS, external couriers. Yet the sense of premium has to be created by us, in the app, in the one place where we control every pixel and every status.

During Discovery, we worked with the client to translate the vague words "premium" and "experience" into concrete product decisions. We ran our proven methodology: the product spec and UX prototypes were built in parallel, signed off, and fed straight into development tasks. The prototypes weren't sketches but high-fidelity — at the client's explicit request, so they could be shown to stakeholders as a finished product. We sized the scope with PERT and a confidence color code (green / amber / red) to reconcile budget and timeline honestly, rather than promise the impossible.

Out of that grew the product philosophy: not a menu list, but a visual, emotional choice of food. A repositioning from "yet another aggregator" to a premium brand with a character of its own.

There's solid evidence that visual presentation directly drives the ordering decision — with food, we "eat with our eyes" before we ever reach the cart. So design became one of the strongest parts of the project and, by the client's own account, one of its main assets.

We designed 150+ unique screens across 31 user flows, in a dark premium aesthetic with gold accents and large, appetizing food photography. But premium isn't only a beautiful storefront — it's the product being thought through end to end. Every scenario has its loading states, empty states, errors, and successes: payment declined, promo code applied or rejected, item unavailable, address outside the delivery zone. Good food UX lives in exactly these details, not just on the home screen.

The order lifecycle is designed as a proper state machine: PENDING → CONFIRMED → PREPARING → READY → courier assigned → DELIVERING → DELIVERED. Every status has its own screen, down to the live courier map and the order-and-driver rating. That continuity is what turns "someone else's" delivery into one coherent, controlled experience.

On top of the base ordering flow sits a premium and social layer: a loyalty program with points balance, tiers, perks, and streaks; gifting and referral codes; per-dish reviews, notes from the chef, a content feed, and chat. Multi-brand and food halls got their own scenarios — food-hall ordering, a multi-brand cart, plus delivery, pickup, and dine-in.

All of it rests on a mature design system: 120+ components with variants, color tokens, a separate library, and full attention to the Arabic interface. The design system lived in every sprint as its own workstream, and the Figma variables table was the single source of truth for tokens.

Architecturally this isn't one app but a connected platform. The contour includes the mobile app and admin back office, our Node.js server layer, a master-data hub, a custom POS, an aggregator hub to decouple from the kitchens, a last-mile delivery orchestrator, a payment gateway, communication channels, a loyalty platform, content storage, and an analytics contour — data warehouse, CRM, and dashboards.

Our area of responsibility was the app, the backend, and the admin panel — and it had to be designed to slot neatly into this landscape without creating chaos in the data. For a platform that integrates with a dozen external systems, that's a discipline in its own right.

This isn't a franchise or delivery from a single restaurant, but potentially dozens of brands, each with its own kitchen, menu, hours, and geozones. We designed a multi-tenant architecture with a flexible "brand → location → branch" model and a configurable level of control on each entity. New brands and venues are added by configuration, without rewriting the app — precisely the tenant isolation and scaling problem that SaaS solves up front rather than after the fact.

The key engineering decision was to move the POS integration into a separate layer. We didn't bake a specific point-of-sale system into the product code; we defined a single internal interface that anything can sit behind — the client's custom POS, an aggregator, or a test environment. As our engineer put it:

This is essentially a classic anti-corruption layer — a pattern that isolates your data model from a foreign one and keeps an external system's quirks from leaking into the product core. The POS can be swapped without rewriting the app. For a project spanning dozens of brands with growth plans, that isn't architectural decoration — it's a survival condition.

At the client's explicit request — they wanted to keep the infrastructure in-house — we built the entire project on Google Cloud Platform. And instead of the usual "containers on top of the cloud" route, we leaned on managed services as far as they'd go: managed PostgreSQL for data, managed Redis for queues (including the notifications queue), Google Cloud Storage for files and images, load balancers — all natively wired inside the platform, with separate staging and production environments.

Deployment was set up from our GitLab straight into GCP, so the client could manage resources from the console. Localization and static onboarding content were moved into remote config (Firebase) so they could be changed without a release. Managed services instead of self-hosted clusters mean less operational load on the team and predictable scaling for the expected traffic. The mobile stack is React Native — a proven choice for foodtech products that keeps iOS and Android on one codebase.

• The client's custom POS — the source of menus, prices, modifiers, images, and stop lists. Through a centralized admin panel, an administrator connects venues and syncs data with one button.
• Deliverect — the aggregator hub through which we decoupled the app from the kitchens' operations.
• Nash — a last-mile delivery orchestrator: a SaaS where you can plug in your own drivers, courier services, and the logic for assigning orders. Multi-region, like the product itself; live courier tracking is built into the ordering experience.
• Tap Payments — an Arabic payment system: online payment and refunds.
• Gameball — the loyalty and gamification engine: points, tiers, challenges, cashback, referrals.
• social.plus — the social features: reviews, dish ratings, stories, feed.
• Firebase (remote config, push) and Google Maps / Places — maps, geocoding, geozones.

Smart address and restaurant switching. When dozens of restaurants under one brand meet the reality of different availability and prices, a plain list stops working. We built something we hadn't built before: when the user changes address or restaurant, the cart is preserved, and the venue list immediately shows which items would disappear where — without opening each restaurant. The list is filtered by availability and sorted by relevance (availability first, then delivery speed). For pickup, the user freely switches restaurants with the cart intact; for delivery, we route to the nearest kitchen to avoid extra load. The client singled this scenario out.

Multi-brand order routing. A separate problem — how to hand an order off to the POS correctly when a single cart spans several brands in one kitchen.

Gaps in the POS API. The kitchen system was missing the endpoints and webhooks we needed — for example, updates when an item goes to a stop list, or notifications that an order is ready. We built the integration against a raw API and designed workarounds so the user never felt it.

Economics at scale. The social platform bills every guest as a paid user — at a base of 160,000–170,000 that threatened an enormous invoice. We deliberately designed the architecture to separate guest traffic from billable traffic and protect the product's unit economics. At scale, "small details" like this decide whether the business model closes at all.

Arabic and RTL. Full Arabic support with interface mirroring was baked in from day one. This isn't "translating strings" but bidirectional layout: mirroring the layout, the direction of icons and navigation, mixed content. Building it in from the start is an order of magnitude cheaper than retrofitting it later.

If your business is a chain or holding living on aggregators, here's a short checklist from our experience:

• Count the sum of commission and data, not just the fee. A first-party channel returns 20–35% of margin and, more importantly, the customer relationship.
• Premium is states, not pictures. Errors, empty screens, order statuses, and courier tracking turn "someone else's" delivery into a coherent experience more powerfully than a pretty storefront.
• Isolate the POS from day one. A single internal interface (an anti-corruption layer) means swapping the point-of-sale system doesn't turn into rewriting the product.
• Multi-tenancy and localization are foundations, not features. The "brand → location → branch" model, multi-currency, and RTL belong in the architecture up front — otherwise every new brand or region costs like a separate project.
• Stress-test the unit economics of every integration at your scale. A service that costs pennies in a pilot can break the whole model at a base of hundreds of thousands of guests.

A product like this isn't "one more delivery app" but a premium foodtech ecosystem, designed to grow alongside the holding: adding brands, regions, and scenarios without rewriting the product. The path from Discovery and a design the client fell in love with to an engineering-mature platform ready to scale is exactly the kind of case where product, design, and engineering thinking have to click into place together.