Opening a Cloud Kitchen in Iraq or the GCC: The Tech Stack That Actually Matters

Why cloud kitchens are the fastest-growing format in the region

Delivery-only kitchens are the cheapest way to launch a food brand in cities where retail rent is expensive and delivery apps already own the customer relationship. Market researchers put the GCC cloud kitchen market at about USD 2.51 billion in 2026, growing around 13% a year toward USD 6.74 billion by 2034, and investors keep backing the model — Kitopi's USD 50 million round in February 2026 was explicitly earmarked for expansion across the Middle East. Iraq has no published cloud kitchen figure yet, but it has the ingredients: a population above 46 million with a median age around 21, and four competing delivery platforms in Baghdad alone (Talabat, Toters, Talabatey and Baly). The catch is that the same apps that bring the orders take a large slice of each one. When Baghdad's restaurant association called a three-day strike in 2026, the trigger was commission rates reaching 27% of order value — and Gulf operators pay similar headline rates of 15–30% before processing and delivery fees. A cloud kitchen that does not measure its channel mix and its ingredient cost per dish is running blind on the two numbers that decide whether it survives.

What a cloud kitchen needs that a restaurant does not

The list is short but unforgiving. One kitchen usually cooks for several virtual brands, so the software must keep menus, prices and reporting separate per brand while stock and stations are shared. Orders arrive from several channels at once and each must reach the right station without anyone re-typing it. There is no server to catch a mistake, so the kitchen ticket must carry every modifier and removal exactly as the customer typed it. Payment is usually settled by someone else — the aggregator, the rider collecting cash, or a wallet — so reconciliation, not the till, is where money goes missing. And with margins this thin, ingredient cost has to be known per dish, per day, not estimated from a monthly stock count.

The three-layer stack, mapped to real features

1 — One order screen for every channel and every brand

Whatever the channel, the order should land in one place and be accepted with one tap. In Culina, each brand or channel can run as its own Culina Profile on the same company — each profile carries its own price list and item selection, so the burger brand and the shawarma brand ring at their own prices while sharing one Kitchen warehouse and one set of stations. Your own ordering channel is built in: the `/order` page is a branded, bilingual online-ordering page, and orders placed there appear on the floor plan as a New order waiting for staff to accept — no floor required, the 'tables' simply become order slots. Aggregator orders are keyed in against the same catalog, so every order carries the same item names, modifiers and recipe. Culina's modifier groups (single choice, multiple choice and removal) with per-option price deltas and Arabic labels are what make 'no pickles, extra sauce, large' survive the trip from the app to the grill.

2 — Kitchen stations and a display that route by brand or category

The second layer is the kitchen itself. Culina's Kitchen Stations route items either by item group — the Grill station takes burgers and kebab, the Fryer takes sides, the Cold station takes salads and drinks — or take all items, and each station can print a paper KOT or show on the Kitchen Display. Sending an order fires one ticket per station carrying the items, their modifiers and the order reference; only new items are sent on a re-fire, so a customer adding a drink never duplicates the burger. On the Kitchen Display, cooks bump items or whole tickets as they finish, and the station tabs, item names and modifiers all follow the active language — Arabic for a Baghdad crew, English for a mixed Doha or Dubai line. For a multi-brand kitchen, name item groups by brand and category (Burger Brand – Mains, Shawarma Brand – Wraps) so one station sees both brands' tickets in one queue.

3 — Recipes that deplete stock on every order, and tenders that reconcile

The third layer is where cloud kitchens live or die. In Culina every menu item can carry a recipe — ingredients with quantity, unit and yield — and the recipe builder shows ideal cost, food-cost % and margin as you type. With Enable Recipe Depletion on, every sale posts a stock entry from the Kitchen / Ingredient Warehouse to the Ingredient COGS account; choose End-of-day depletion timing for a high-volume delivery kitchen so one aggregated entry per profile is posted instead of hundreds. Cancelled or returned orders reverse the depletion. The Menu Engineering report then places every recipe-backed dish on a Star / Plowhorse / Puzzle / Dog matrix by units sold and contribution margin per unit — money per plate, not cost percentage — which is exactly the view a virtual-brand founder needs to decide which dish to push in the app. On the money side, set up each way you get paid as its own mode of payment: Cash on Delivery, Zain Cash, Qi Card, FastPay and each aggregator as a receivable, each posting to its own account, so a shift's Z-report shows expected against counted per tender and the aggregator's weekly settlement can be matched line by line.

A worked example: a two-brand cloud kitchen in Baghdad

Take a delivery-only kitchen in Karrada — call it Matbakh Al-Karrada — running a burger brand and a shawarma brand from one line. It does 180 orders a day at an average ticket of IQD 15,000, and it trades seven days a week. Sixty percent of orders (108) come through aggregator apps at a 25% commission; forty percent (72) come through the kitchen's own ordering link and are delivered by its own rider at IQD 2,500 per trip, paid cash on delivery or by Zain Cash. Packaging costs IQD 1,000 per order. Recipe depletion shows real food cost at 32% of gross sales. Here is one day:

Over a 30-day month the kitchen contributes IQD 32,130,000 (1,071,000 × 30) before rent, labour and utilities — about USD 24,715 at the 2026 budget rate of IQD 1,300 per dollar. Now the two levers. First, channel mix: moving just 20 orders a day from the apps to the kitchen's own link saves IQD 75,000 in commission (20 × 15,000 × 25%) and costs IQD 50,000 in extra rider trips (20 × 2,500), a net gain of IQD 25,000 a day or IQD 750,000 a month (about USD 577) — which is why the QR code and the ordering link belong on every bag. Second, food cost: the recipe-based figure is 32%, against a 30% target for these menus. That two-point gap is IQD 54,000 a day (2% × 2,700,000), or IQD 1,620,000 a month (about USD 1,246) — and it is only visible because depletion runs per sale. A monthly stock count would show the same loss thirty days late, blended across both brands, with no way to tell whether the burger line over-portions cheese or the shawarma line wastes bread.

The bottom line

A cloud kitchen in Iraq or the GCC does not need a bigger POS; it needs a narrower one that does three things without gaps: take every channel and every brand into one order screen, route every item to the right station with its modifiers intact, and deplete recipes on every sale while posting every tender to its own account. Culina, a restaurant management system built on ERPNext and used across the GCC and Iraq, provides all three — profiles per brand on one company, kitchen stations with KOT and a bilingual Kitchen Display, a built-in online-ordering page, modifiers with Arabic labels, recipe depletion with end-of-day timing for high volume, a Menu Engineering report, and modes of payment for cash on delivery, Iraqi wallets and aggregator settlements — so the numbers that decide a delivery kitchen's survival are on screen every day, not in a spreadsheet at month-end.