Cloud Kitchens: What Counts as a Location?

Devfood is priced per location, and cloud kitchens are the customers who most often ask what that word means. A kitchen with no dining room, three menu concepts and a delivery radius does not look like a “location” in the way a corner café does. So here is the definition we actually bill on, the cases it produces, and the one boundary it does not cross.

The definition

From the pricing page:

One physical outlet that takes orders. A single brand with three kitchens is three locations; a dark kitchen preparing for one storefront is one.

The metric is physical outlets that take orders. Not brands, not menus, not delivery zones, not order volume. One kitchen at one address is one location, whatever it cooks.

Orders are unlimited on every plan and carry no commission, so a location’s bill is the same at two hundred orders as at two thousand. What changes the bill is the count of sites, and it changes in your favour: your fourth location moves the whole account to the 4–9 rate, and your tenth moves it to the 10+ rate. In India that ladder is ₹2,100, then ₹1,800, then ₹1,575 a month per location; every published market has its own row.

The cases

One kitchen, three menu concepts. A kitchen in Bengaluru cooking a biryani menu, a burger menu and a salad menu under three names. That is one location. Set each concept up as its own outlet in the dashboard, with its own menu, hours and price book — the platform’s multi-outlet tooling is built for exactly that — and run all three from one screen. The bill is one location’s.

One brand, three kitchens. The same three menus cooked in three neighbourhoods, each kitchen with its own delivery radius. That is three locations. Each one takes its own orders and dispatches its own drivers, and the account sits on the 1–3 rate.

One kitchen feeding one storefront. A dark kitchen that prepares food for a single shop that takes the orders. That is one location, because there is one point where orders arrive. Where the food is cooked does not create a second location.

A kitchen plus a counter at the same address. If the counter takes its own orders — walk-in, pickup, a kiosk — it is a second outlet in the product and a second location on the bill, because it is a second place that takes orders. If the counter is just a collection window for orders the kitchen already took, it is not.

A fourth kitchen. The day it opens, the account moves to the 4–9 rate for all four. There is nothing to renegotiate; the ladder is published and it applies automatically.

Why brands are not the metric

Several platforms charge per brand, per menu or per storefront, which turns a multi-concept kitchen into the most expensive kind of customer — precisely the model that made virtual brands attractive in the first place gets taxed.

We chose the physical outlet for two reasons that are about value rather than cost. First, outlets are already a first-class entity in the product rather than a proxy invented for billing: menus, price overrides, staff roles, data scoping and reporting are all per outlet. A ten-kitchen operator takes roughly ten times the value out of the platform that a single kitchen does, so ten times the price is fair, and a flat fee would have made the largest customers pay the least per unit. Second, it is the unit the category already quotes in, so you can compare us with anything else on the same denominator.

The honest limit of that argument: per-location is a value metric, not a cost metric. Nothing is installed at your kitchen on the base plan, so we never defend it as “what your extra site costs us to run”.

What a cloud kitchen gets on the base plan

Everything in the subscription is the same at every tier and every band — there are no feature tiers, only a price ladder. For a delivery-only operation the relevant parts are:

• Branded ordering on web, iOS and Android, with the native app build and store publishing included. A cloud kitchen has no shopfront; the app is the shopfront.
• Delivery zones not capped by plan, drawn as polygons per outlet, with flat, distance-based or zone-based fees and a minimum order per area.
• A driver app with background GPS and auto-dispatch, scoring drivers on distance, load and vehicle type — plus on-demand fleets from DoorDash Drive, Uber Direct, Shipday and Nash where they operate.
• Loyalty wallet, cashback and vouchers, because a customer who cannot walk past your door has to be brought back deliberately.
• Multi-language storefronts, included rather than sold as a pack.
• 75+ built-in reports with CSV export, per outlet and rolled up.

The counter hardware — register, kitchen display, self-order kiosk, loyalty tablet — is optional and quoted separately, and a kitchen with no counter needs none of it. Kitchen ticket printing to Bluetooth thermal printers and PrintNode is in the base plan, so the tickets still land where the cooks are.

The boundary: your kitchens, not other people’s

One case is not a Devfood customer, and it is better to know now. If the “brands” in your kitchen are independent businesses and you take a percentage of their sales, you are running a marketplace. That needs vendor onboarding, per-vendor payouts and commission splitting, none of which Devfood has. Our sister company Devkart builds SuperApp for exactly that, and it is priced per order rather than per location.

Devfood is for a brand that owns or operates its own kitchens — however many that is, and however many menus they cook.

Working it out for your own setup

Count the places where orders arrive. That is your location count; look it up on the pricing page in your market’s currency, and remember the account moves down the ladder as the count rises. If your setup does not map cleanly onto the cases above — a shared kitchen with a partner, a counter that sometimes takes orders — book a demo and describe it. We will say which count applies before you sign anything, and if the answer is “this is a marketplace”, we will say that too.