Ghost Kitchen Software: Routing Orders Across Brands Without Losing Margin

Why order routing software makes or breaks a ghost kitchen operator

You run six brands out of one 1,100 square foot production kitchen. Wing concept, birria concept, salad concept, two pasta brands you licensed, and a late-night smash burger label that does 60% of its volume after 9pm. Six brands times three marketplaces times four locations is 72 live menu instances. Every one of them can drift.

The stack is usually the same: Toast or Square running the register that nobody uses, Otter or Deliverect or ItsaCheckmate injecting DoorDash, Uber Eats and Grubhub tickets into it, a Fresh KDS screen bolted over the pass, a shelf of tablets that still get touched because two brands never got API approval, and a Google Sheet where the ops manager tracks which brand is actually making money. Marketplace commission is published at 15%, 25% or 30% depending on the plan you signed. Nobody in your building can tell you, on a Tuesday, what your wing brand's contribution margin was on Monday.

It is 11:47 on a Thursday. Thirty-one tickets hit in nine minutes across five brands. The fryer is the constraint for three of them. Your KDS shows tickets in arrival order, not station order, because it has no idea that "Nashville Tenders" and "Crispy Chick'n Sando" and "Loaded Fry Bowl" are the same fryer basket wearing three logos. A DoorDash Dasher walks in at minute four for an order the line has not started. He waits eleven minutes, marks it late, and the store's rating drops. Your GM's fix is to pause the burger brand on Uber Eats from a tablet, which he forgets to un-pause until 1:20pm. That is 90 minutes of a channel dark during peak, and it happens two or three times a week per location.

One protein runs out and forty SKUs stay live

Prep runs out of the braised birria at 7:40pm. That single ingredient sits inside 11 menu items across three brands, and those 11 items exist separately on DoorDash, Uber Eats, Grubhub and your own site. That is 44 listings a human now has to find and toggle off, on four different merchant portals, during service. What actually happens: someone 86s the obvious four, misses the quesabirria on the pasta brand's "chef's picks" section, and you eat nine refunds plus a "missing or incorrect item" error charge on each.

Off-the-shelf middleware cannot fix this because it models items, not ingredients. Otter and Deliverect will happily push a snooze across channels for the exact SKU you tell them about. Neither one knows that SKU 4471 and SKU 8802 share a component. There is no recipe layer, so there is no dependency graph, so a human has to hold the graph in their head at 7:40pm.

A custom build inverts it. You model ingredients and sub-recipes as first-class entities, map every channel SKU to a bill of materials, and then 86ing is a single event on the component. The system walks the dependency graph and fires snooze calls to every affected listing on every channel in under a second, then auto-restores when the next prep batch is logged. Depletion runs off actual ticket flow, so the system predicts the 86 twenty minutes out and pings the expo screen: "birria at 14 portions, projected out at 8:05." AI does concrete work here: a per-brand, per-daypart demand model trained on your own 18 months of ticket history sets tomorrow's prep pars per component, and flags the ones where yesterday's par was 30% off. Prep sheets stop being the AM lead's guess.

Your KDS sorts by brand when your kitchen is sorted by station

Ghost kitchens are stations wearing brand costumes. The line does not care that the ticket says "Pasta Sorella." It cares that the item needs the boiler, then the saute pan, then the cold assembly bench. Every off-the-shelf KDS, including Toast's and Fresh KDS, routes by order and by concept because it was designed for a dine-in restaurant with one menu.

So your fryer guy sees six tickets from six brands, each with one fryer item, sequenced by arrival. He fries them one at a time. Basket utilization sits around half, throughput craters, and your promise times inflate, which is exactly what the marketplace ranking algorithms punish.

What we build instead: a routing engine that explodes each order into station-level tasks, batches like tasks across brands inside a courier-arrival window, and sequences backward from the latest allowable ready time. The fryer screen shows "12 tenders, 4 baskets, drop now" instead of six separate tickets. The expo screen is the only place brands reappear, for bagging and label printing. Two data flows make it work: a live station-capacity model, and courier ETA polled from each marketplace's order API so the sequencer knows which orders can wait 90 seconds and which cannot. In our experience across multi-brand kitchen builds, station batching is the single largest throughput gain available, and no packaged product will ever ship it, because it only makes sense when many brands share one line.

Nobody can tell you what a brand actually earns

Your P&L is per location. Your decisions are per brand. Should the salad concept die? Should you push the burger label to the other three kitchens? Right now the answer comes from a spreadsheet where someone allocates rent and labor by revenue share, which is a fancy way of saying the answer is unknowable.

Restaurant365 and MarginEdge do good back-office work, but they reconcile to a location and a vendor invoice. They have no concept of a virtual brand consuming 22 minutes of fryer time and 3 minutes of a packer's hands. Otter reports revenue per brand and stops there, because it never saw your invoice from US Foods.

The build: parse vendor invoices into line items with unit costs, attach costs to components, and let the bill of materials push a true food cost onto every ticket in real time. Labor gets attributed by station-seconds, not revenue share, using the same task model that drives the KDS. Commission, promo spend and error charges get pulled from each marketplace's report API and attached to the exact order. Now a brand has a contribution margin per order, per daypart, per location, and killing the salad concept is a two-minute decision. Document extraction is a genuine AI use here: invoices from Sysco, Restaurant Depot and a dozen local produce vendors arrive as PDFs and photos with inconsistent formats, and a model that maps them to your component catalog with a human confirming low-confidence lines removes roughly a day a week of a bookkeeper's time per kitchen.

The payout statements nobody reads

Marketplace deposits land net of commission, net of promo participation, net of adjustments, net of error charges for missing or incorrect items, and net of chargebacks. Each platform formats this differently. Each has a dispute window measured in days. At three locations and six brands you are looking at thousands of order-level adjustments a month, and nobody at your company reads them.

We have watched operators find five figures a year of never-disputed error charges once the data was actually assembled. Not because the marketplaces are villains, but because the dispute window closes while the statement sits unread in an inbox.

A custom reconciliation layer ingests every payout report, matches each line to the order in your system, and auto-flags variances: charged commission that does not match your contracted rate, refunds on orders where your own KDS photo shows a complete bag, duplicate adjustments. Disputes get filed inside the window with the evidence attached, automatically. None of this is interesting to build. It usually pays for a meaningful slice of the project anyway.

What it costs and how long it takes

Framed only on Digital Heroes delivery experience across 2,000-plus projects: a focused first release runs $60k to $130k and ships in 12 to 16 weeks. That buys unified order intake from two or three marketplaces, the component and bill-of-materials layer with cross-channel 86 propagation, a station-routed KDS, and payout reconciliation. A full platform, adding per-brand costing from invoices, forecasting, a direct-order channel with your own couriers, and multi-tenant support for licensed kitchens, runs $150k to $400k phased over 6 to 12 months.

What drives price up in this category specifically. First, marketplace API access: DoorDash, Uber Eats and Grubhub each require partner approval and certification, and those cycles are calendar time you cannot compress with money. Second, POS (Point of Sale) integration depth, since Toast and Square partner APIs each have their own certification and their own gaps. Third, offline resilience, because a kitchen with a dead internet connection still has to cook, and building a local-first KDS that reconciles on reconnect is roughly a third more work than a cloud-only one. Fourth, hardware on the line, which means ruggedized screens, label printers and the integration tax each brings. Fifth, every additional country, because menu and tax models diverge hard.

Build versus buy, honestly

If you run one to three kitchens, four brands or fewer, under about 250 orders a day, and your menus are stable, do not build. Otter or Deliverect or ItsaCheckmate plus Toast will cost you a few hundred dollars a month per location and solve 80% of your problem. Anyone telling you to build custom software at that scale is selling you something.

The signals that it is time: you are past roughly eight brand-by-channel-by-location combinations. Someone on payroll spends more than a day a week reconciling payouts or updating menus. You are licensing your brands to third-party kitchens and need per-licensee reporting the middleware cannot give you. Your direct channel is past 20% of volume and the 30% commission you are avoiding is now worth real engineering. Or the decisive one: you have a repeatable operating advantage, like station batching or dynamic menu pricing by daypart, that your competitors cannot copy because it lives in your software. That is when the build stops being a cost center.

How to choose a developer for ghost kitchen software

Ask them to model the domain on a whiteboard before you talk price. Brand, concept, location, station, component, sub-recipe, channel SKU, order, task, courier. If they draw "restaurant, menu, order," they have built a food-ordering app and not a ghost kitchen platform, and you will pay to teach them the difference.

Ask what happens when the DoorDash menu push fails at 6pm on a Friday. The right answer involves idempotency keys, a retry queue, a divergence detector that compares your source of truth against what is live on each channel, and an alert to a human. The wrong answer is "we handle errors."

Ask which marketplace and POS certifications they have already been through. Partner approval calendars are the real project risk in this category, and a team that has cleared DoorDash and Toast before will start those clocks in week one instead of week nine.

Ask about the boring compliance surface: HACCP temperature logging tied to your equipment, allergen data flowing correctly onto every channel listing, per-brand DBA and delivery-only permits where your jurisdiction requires them, and PCI scope on the direct channel. A developer who says "we will just use Stripe" without explaining how that keeps card data out of your systems has not thought about it.