Ghost Kitchen Software: Why Running 3 Brands Out of One Kitchen Breaks Standard Restaurant Tech

Friday, 7:30 PM. Peak hour. BurgerDrop gets an order through DoorDash, TacoRun through Wolt, SaladBox through UberEats. All three land in one POS as orders from a single restaurant. The kitchen display shows three tickets in a row with no brand marking. The grill cook has no way of knowing that BurgerDrop and TacoRun are separate concepts with separate prep workflows. SaladBox's salad waits in a queue it never needed to join.

The cooks are doing everything right. What's failing is the architecture — a stack that was never designed to run three parallel operations under one roof. A ghost kitchen with three brands runs three different menus, three sets of aggregator storefronts, and three kitchen workflows simultaneously, while the standard restaurant tech stack sees all of it as one location. That mismatch is the source of most operational failures in dark kitchens today — and it matters more every quarter, as the global cloud kitchen market is projected to grow from $88.7 billion in 2026 to $203.7 billion by 2033, according to Grand View Research.

Our team builds FoodTech products for delivery operations — Sizl, a Chicago dark kitchen whose app we rebuilt on React Native in 2.5 months, along with FoodClick, TikTak, and Yapoki. Multi-brand operations break in four predictable places, and this guide walks through each one — POS routing, aggregator menus, kitchen view, merchant portal — with what actually needs to sit at every level.

Ghost kitchen software is the operational technology layer that manages order intake, brand routing, kitchen execution, and aggregator integrations for delivery-only restaurant operations — especially when multiple virtual brands share one physical kitchen. The keyword is multiple, simultaneously. A standard POS was designed around one brand, one menu, one order stream. Ghost kitchen software exists because a multi-brand dark kitchen violates all three assumptions at once.

One honest terminology note, since the question comes up constantly: ghost kitchen and dark kitchen describe the same delivery-only model without a dining room. Ghost kitchen usually refers to the business side — a virtual, delivery-only brand. Dark kitchen usually refers to the physical facility built or converted for delivery production. In practice one dark kitchen often runs several ghost kitchen brands, and the software requirements are identical. This article uses both terms interchangeably.

Three scenarios push an operation past what standard restaurant software can handle:

1. Two or more brands out of one kitchen, each with its own menu on its own set of aggregators.
2. One brand on three or more aggregators, with different prices on each platform.
3. Multiple kitchen stations (grill, fry, cold prep) running different workflows for different brands.

If none of these applies, a standard setup — Toast plus Deliverect — will cover about 90% of your needs; the final section maps exactly where that line runs. The architecture question sits inside a bigger picture of how delivery system architecture affects dark kitchen growth, and if you want to see where ghost kitchen software fits in the broader restaurant technology ecosystem, we mapped the full stack in a separate guide.

Standard POS systems — Toast, Square, Syrve, Poster — store menus and orders at the location level. There is no brand field in the transaction log. When three virtual brands operate from one physical address, a DoorDash order for BurgerDrop and a Wolt order for TacoRun both arrive as orders for "Location #1." Revenue can't be split by brand without manual reconciliation, loyalty can't work per brand, and the kitchen can't route by brand-specific workflow. Brand separation at the order level is the first thing to check in a dark kitchen stack — and standard configurations ship without it.

Two architectural fixes exist, each with real trade-offs:

Virtual locations in the POS. One physical address registers as several logical POS "locations" — one per brand. It works out of the box with most major systems (Toast and Square both support it). The downside: billing is per location, so subscription cost multiplies with every brand, and inventory sync between "locations" that share one walk-in fridge becomes its own engineering problem.

Middleware with brand_id injection. All aggregator orders pass through a middleware layer — Deliverect, Otter, or a custom service — before reaching the POS. The middleware stamps a brand_id into every order payload, so the POS receives orders already tagged. One POS account, clean per-brand analytics. The trade-off is a dependency on one more layer in the chain.

The cost math usually decides it: virtual locations multiply per-location subscription fees with every added brand, while a middleware layer costs the same whether it routes two brands or five. Which route fits depends on brand count, order volume, and how far your POS can stretch — our breakdown of what a standard POS is designed to do and where it stops covers that boundary.

In a multi-brand dark kitchen, the menu stops being a single document. It becomes a matrix: brand × aggregator × price tier. BurgerDrop on DoorDash can run 15% above its direct-channel prices to absorb the platform commission. TacoRun on Wolt can carry a shortened menu because half its items degrade past a 20-minute delivery window. That variation is deliberate strategy, and there are three standard reasons behind it:

1. Commission compensation. Marketplace plans on major platforms charge restaurants 15–30% per order depending on the tier. Different aggregators, different commissions — the aggregator economics behind per-platform menu pricing run deeper than most operators budget for.
2. Delivery-window menus. Items that lose quality in transit come off the aggregator menu but stay available for pickup in the direct channel.
3. Platform-exclusive items. A promo dish that exists only on Wolt as part of a marketing deal.

A standard POS holds one menu per location, so this matrix has to live somewhere else: a menu management layer above the POS that stores the master menu and publishes aggregator-specific versions through each platform's API, with scheduled sync plus webhooks on change. Each platform behaves differently in practice: Wolt runs a stable REST API with webhook-based menu sync; DoorDash ships frequent API updates that demand regular maintenance; Glovo offers more limited programmatic menu access; UberEats has a powerful API with strict certification requirements; Grubhub, still relevant for US dark kitchens, runs its own API with its own quirks. Each integration is a separate maintenance burden, and the codebase architecture has to keep them from drifting apart — on Sizl's rebuild, a monorepo covering the customer app, courier app, and support tool kept releases in sync across one codebase.

Skip this layer and you get menu drift: the Wolt menu gets updated, the DoorDash one doesn't, a discontinued item keeps selling on one platform, and the result is refunds, complaints, and a sinking platform rating. We've broken down more of these delivery integration failures that cost dark kitchens money separately.

Running the same brand on three aggregators with three different menus — and syncing them by hand? Book a call and we'll map which parts of that matrix can be automated in your setup

Max B., CEO

Write in LiveChat

Write in LinkedIn

A single kitchen view means one operational interface showing every order from every brand — with hard separation by brand, order type, and kitchen station. Four things distinguish it from a stock KDS:

1. Brand indicator on every ticket. A color, icon, or brand name readable from two meters away. Standard KDS ships without it.
2. Station routing. A BurgerDrop item goes to the Grill screen; a SaladBox item goes to Cold Prep. Without routing, every ticket hits every screen and cooks learn to ignore most of what they see.
3. Priority by order type and brand. A delivery order with a courier arriving in eight minutes outranks a pickup order with a relaxed window, and brands with different average prep times need different queue logic.
4. Real-time stop-list management. An ingredient runs out, the cook flags it on the KDS, and the item drops off every aggregator menu automatically. Otherwise the platform keeps accepting orders for a dish the kitchen can't make.

Sequence matters here: the kitchen view belongs at the start of the architecture, ahead of the customer-facing app. A polished ordering interface layered over broken kitchen routing produces orders that arrive on time into a kitchen that can't tell them apart — operational chaos with a good-looking front end.

One technical requirement gets missed constantly: the KDS must run offline-first, on the local network rather than the cloud. If the internet drops during Friday peak, orders keep flowing from the POS over LAN. A cloud-dependent KDS turns a connectivity blip into a stopped kitchen — and kitchen system uptime is non-negotiable during peak hours. How the kitchen screen connects back to the delivery layer is part of how delivery systems connect to kitchen operations in a dark kitchen setup.

Every aggregator gives you its own back office: Wolt Partner Portal, DoorDash Merchant Portal, Grubhub for Restaurants. For a dark kitchen running three brands on three platforms, that means nine separate interfaces for monitoring orders, editing menus, and reading analytics — each with its own logic, data format, and UX. A unified view of the operation simply doesn't exist. That absence is the problem.

A merchant portal built for a multi-brand dark kitchen needs five capabilities:

1. One live order feed — every order, every brand, every aggregator, filterable by brand, platform, and status.
2. Cross-aggregator menu management — change a BurgerDrop price once and it propagates to every platform where the brand lives, with per-aggregator price overrides where needed.
3. One-action stop-lists — pull an item from all aggregators in a single move when an ingredient runs out mid-shift.
4. Brand-level analytics in real time — revenue, average order value, rejection rate, and prep time split by brand, aggregator, and time range. Without it, the P&L for each virtual brand gets assembled by hand in a spreadsheet. What cross-brand analytics actually requires at the data layer is a deeper topic than most operators expect.
5. Courier status visibility — the kitchen needs to see that a courier has arrived and been waiting five minutes, so the right order jumps the queue.

Honest comparison: Deliverect, Otter, and Hubster deliver a unified order feed and solid menu management — they work well as the middleware layer. What they don't provide is custom brand-level analytics, a custom kitchen view, or a white-label portal for partner brands. A custom merchant portal earns its cost at 3+ brands, 3+ aggregators, or wherever aggregator relationships push operational complexity past what SaaS dashboards can configure.

A ghost kitchen tech stack has five layers, and every one of them carries load in a multi-brand operation:

Most dark kitchens build this stack bottom-up: POS first, then delivery integrations, analytics someday. The breakage almost always happens in the middle — brand routing and kitchen execution — because those layers look optional on day one. With a single brand and forty orders a day, manual workarounds hold. The failure surfaces two to four weeks after adding a second or third brand, when volume grows and the symptoms arrive together: kitchen confusion at peak, menu drift across platforms, and a P&L that can't be split by brand. The middle layers are the ones to design first, precisely because they're the hardest to retrofit — a pattern that stands out sharply against how a standard restaurant technology stack carries load.

Custom development pays off only past a specific complexity threshold. Below it, off-the-shelf tools win on speed and cost.

A standard stack (POS + Deliverect + the aggregator's native portal) covers you when:

• You run 1 brand on 1–2 aggregators.
• You have no cross-brand analytics requirement.
• The kitchen is linear — no station separation with different workflows.
• Order volume stays under 80–100 per day, well within SaaS middleware capacity.
• The development budget is tight and launch speed matters more than architectural headroom.

Custom ghost kitchen software becomes the right investment when:

• You run 2+ brands out of one kitchen with different menus.
• You operate on 3+ aggregators simultaneously — especially with per-platform pricing.
• You need brand-level analytics and a real P&L per virtual brand.
• You plan to scale to 5+ kitchen locations.
• You run white-label operations — partner brands under third-party management in your kitchen.

The honest answer on Deliverect vs. custom: Deliverect and Otter solve order aggregation and menu sync well. They don't solve brand-level kitchen routing, custom analytics, or a white-label merchant portal. For the first six months of a multi-brand operation, Deliverect is the right call. Past six months, with more than three brands or more than three aggregators, custom starts earning its keep — and there's a sane way to phase ghost kitchen software development: start lean, scale with custom. Speed and phased scope go together: Sizl's app rebuild on React Native shipped in 2.5 months, and the company went on to raise a $3.5 million seed round to expand its kitchen network in Chicago.

Before talking to any vendor, it helps to know how to scope your ghost kitchen software requirements on paper first — half the cost surprises in custom development trace back to a brief that never mentioned brand routing.

Not sure which side of that threshold your operation is on? Book a discovery call

Max B., CEO

Write in LiveChat

Write in LinkedIn