By Devfood Team — who we are
Food Courts: One Roof, One Delivery Fleet
How an operator running several counters under one roof takes one order across all of them, routes it to each kitchen, and dispatches one pool of drivers.
A food court run by one operator is a strange shape for ordering software. It has one address, one brand over the door, and six or eight kitchens that each cook their own menu at their own pace. Customers want one order — a bowl from one counter, a drink from another — and the operator wants one driver to carry it. Most platforms model this as six separate restaurants and leave the operator to stitch them together. This is how Devfood models it as one.
One storefront, several kitchens
Each counter is set up as its own outlet in the dashboard: its own menu, its own hours, its own price book, its own staff. What the customer sees is one branded storefront across every counter. They browse all of them, build one cart, check out once and pay once. Behind that single checkout, the order is routed per kitchen — every counter receives the lines it has to cook, in its own prep queue, and nothing else.
That routing is what makes the model work at the pass. A counter’s cooks see a ticket for their dishes only, on whatever they already use: a Bluetooth thermal printer (Sunmi, Rongta, Star, or a generic BLE printer), a PrintNode cloud printer, or the restaurant app’s live-orders board on a phone or tablet at the counter, with New, Accepted, Processing and Ready lanes and a prep time set on accept. When a counter runs out of something, staff 86 it there and it disappears from the shared storefront until the time they pick.
Branding and promotions stay central. One set of colours and one app name over all of it, and a voucher campaign or a discount that applies across every counter or to just one.
One driver pool
A food court’s delivery problem is that six kitchens generate six trickles of orders, none of which justifies its own fleet. Devfood attaches drivers to the outlets they serve, so one pool of drivers is assigned to every counter under the roof and a single order that spans three of them leaves in one bag with one driver.
Dispatch is automatic. The engine scores available drivers on distance, current load and vehicle type, and offers the order in one of three modes you choose per outlet:
- One-by-one — offered to the best-scoring driver, then the next if they decline. Fairest to drivers, slowest at peak.
- Send-to-all — broadcast to every eligible driver, first to accept takes it. Fastest at peak.
- Nearest-first — assigned to the best driver outright, with no acceptance step.
Manual dispatch is always there for the exceptions. Drivers run the driver app on iOS or Android with background GPS, customers watch the delivery on a live map with an ETA, and proof of delivery is captured at the door.
When your own pool is saturated — a rainy Friday, a match night — on-demand fleets from DoorDash Drive, Uber Direct, Shipday and Nash can take the overflow where they operate, from the same dispatch screen.
Zones and fees for a shared address
Every counter shares one front door, so the delivery geography is one geography. Draw the polygon service areas once per outlet — they will be the same shape — and price them with a flat, distance-based or zone-based fee and a minimum order per area. Zones are not capped by plan, so a court that delivers to three neighbourhoods at three fees draws three.
Because the customer pays once, they pay one delivery fee for the whole bag, however many counters filled it. That is the difference between a shared fleet and six restaurants on a marketplace, where the same customer pays six delivery fees or does not order at all.
What it costs
Devfood is priced per location, and the pricing page defines a location as one physical outlet that takes orders. Each counter takes its own orders, so a court with six counters is six locations — and six locations is on the 4–9 rate, because your fourth location moves the whole account down the ladder.
In the Philippines that rate is ₱982 a month for each location, so a six-counter court pays ₱5,892 a month for unlimited orders across all of them, with no commission and no per-order fee. In India it is ₹1,800 for each; in Brazil, R$127. A tenth counter moves the account to the 10+ rate. Every counter is on the same single plan — there are no feature tiers, only the ladder.
Nothing is installed at the counters on the base plan. A kitchen display, a self-order kiosk, a register or an in-store loyalty tablet are optional add-ons quoted separately, and a court with printers at every pass may want none of them.
The boundary
All of this assumes the counters are yours — one operator running its own kitchens under one roof, whether that is a mall food court, a hawker-style hall you lease and staff, or a campus canteen with several stations.
If the counters are independent businesses and you take a percentage of their sales, you are running a marketplace, and Devfood is the wrong tool. A marketplace needs vendor onboarding, per-vendor payouts and commission splitting, none of which Devfood has. Our sister company Devkart builds SuperApp for that, priced per order rather than per location. We would rather say so on the first call than watch you discover it in month two.
Setting one up
- Create one outlet per counter, with its menu, hours and price book.
- Enrol each counter’s printer or tablet, so tickets land where that counter cooks.
- Add your drivers and assign each of them to every outlet they serve — for a shared fleet, that is all of them.
- Draw the delivery zones once and reuse the shape.
- Pick a dispatch mode. Start with one-by-one and a generous acceptance timeout; switch to send-to-all if peak-hour offers are timing out.
Book a demo on a live store and bring your floor plan. Mapping counters to outlets takes a few minutes, and it is the one decision that everything else follows from.