Ordering in Emerging Markets – Blog | Devfood

Cloud Kitchens: What Counts as a Location?

Wed, 02 Sep 2026 00:00:00 GMT

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.

Direct Ordering Math for an Indian Restaurant

Wed, 02 Sep 2026 00:00:00 GMT

Most of the break-even articles written about direct ordering are worked in US dollars, against US commission rates, at a US subscription price. That is three numbers an Indian restaurant cannot use. This one is worked in rupees, at the price Devfood actually publishes for India, and it is honest about the one number we could not verify.

The two cost models, in rupees

A marketplace charges a percentage of every order. Your cost rises with your sales; a good month is an expensive month.

A subscription inverts that. Devfood’s Indian price for one to three locations is ₹2,100 a month per location, with no commission and no per-order fee. Two hundred orders or two thousand, the bill is the same. From your fourth location the rate is ₹1,800, and from your tenth it is ₹1,575 — the whole account moves to the lower rate, not just the new site.

That price is not a currency conversion of the US figure. In the US the same plan is $79 per location, and converting that into rupees would produce a number that has nothing to do with what an Indian restaurant pays for software. India is priced against what Indian restaurants already pay for a comparable stack — the method is explained in why ordering software should not be priced by exchange rate.

The commission rate — what is and is not published

The break-even depends on one input we cannot supply for you: the effective rate your marketplace takes.

We checked the restaurant-partner pages of both major Indian aggregators on 2 September 2026. Neither publishes a commission rate on them — Zomato’s partner page loads a sign-up shell and Swiggy’s partner site goes straight to a login. Rates are set per restaurant in the onboarding agreement, so the only trustworthy figure is the one on your statement.

So the numbers below use a stated assumption: an effective rate somewhere between 15% and 25% of order value, after the delivery fee passed to the customer is excluded. Take last month’s payout statement, divide total deductions by gross order value, and replace the assumption with your own figure. The formula does not care which number you use; it only cares that it is yours.

The break-even formula

break-even direct sales per month = monthly subscription ÷ effective commission rate

At ₹2,100 a month for a single location:

Effective rate	Break-even direct sales / month
15%	₹14,000
20%	₹10,500
25%	₹8,400

Turn that into orders. At an average ticket of ₹350 and a 20% effective rate, the subscription pays for itself once 30 orders a month come through your own channel — one a day. At a ₹250 ticket it is 42 orders. At ₹500 it is 21.

Everything above that line is margin you keep rather than remit. A restaurant doing ₹3 lakh a month through marketplaces at a 20% effective rate is remitting ₹60,000 a month in commission. Moving a third of that volume direct saves roughly ₹20,000 a month against a ₹2,100 subscription.

What the formula leaves out

Card processing still exists. Devfood connects your own payment gateway account, and the gateway bills its processing fee to you directly — there is no markup in the middle. Which gateways are available depends on the market, so ask us which ones apply to India before you plan around one. Compare commission above processing, which is how a marketplace statement usually breaks it out anyway.

Cash on delivery is a channel here, not an edge case. Devfood supports it alongside card and wallet payments, and a cash order carries no gateway fee at all. If a meaningful share of your direct orders will be cash, your effective saving per order is the full commission.

Setup and billing terms. On monthly billing there is a one-time $299 setup fee for the app-store publishing, domain and go-live work; on annual billing it is included, and you pay ten months for twelve. Fold that into a first-year calculation rather than a monthly one.

Third-party costs that are yours either way. An Apple developer membership for the iOS app, SMS for OTP sign-in, and map API usage for addresses and live tracking are billed by those providers, not by us. They are small, but they are real, and they are listed on the FAQ rather than hidden.

What it leaves out — in your favour

The customer becomes yours. On a marketplace the platform holds the relationship, and reordering happens inside their app, beside your competitors. On your own channel the customer, their order history and the ability to bring them back with a voucher or a wallet credit belong to you. That is the whole reason to run the channel, and the break-even formula cannot price it.

No menu inflation. Restaurants commonly list higher prices on marketplaces to absorb commission. A direct channel lets you list the real price, which is a reason for a regular to switch on its own.

Busy months stop being expensive months. Diwali week costs the same as a quiet Tuesday in August.

What it leaves out — against you

A direct channel does not come with a marketplace’s audience. You have to point your own customers at it: a link on Instagram and WhatsApp, a QR code on the bill and the packaging, a line on the receipt. The restaurants that do best treat the marketplace as acquisition for strangers and their own app as the default for regulars — the first order is discovered on the marketplace, the tenth is placed direct.

That is also why the break-even number matters. You do not need to move your whole volume; you need to move about 30 orders a month at a ₹350 ticket. Your regulars cover that on their own.

Running your own numbers

Pull last month’s marketplace payout statement.
Effective rate = total deductions ÷ gross order value.
Break-even sales = ₹2,100 ÷ that rate.
Break-even orders = break-even sales ÷ your average ticket.

If that order count looks small next to your monthly volume — for most established restaurants it does — the question is no longer whether the channel pays for itself, but how quickly you can point your regulars at it. Book a demo and bring a statement; the calculation takes five minutes on a call.

Do You Need the In-Store Suite on Day One?

Wed, 02 Sep 2026 00:00:00 GMT

Devfood’s subscription buys four connected apps and nothing bolted to a counter. The register, the kitchen display, the self-order kiosk and the in-store loyalty tablet exist, and plenty of operators run them — but they are optional add-ons quoted separately, not part of the base price. That split is deliberate, and it raises a fair question from anyone opening a new site: do I need any of it on day one?

Usually not. Here is how to tell.

What the base plan already puts at the counter

The four apps are the customer app, the restaurant app, the driver app and the admin dashboard. Two of them do more counter work than people expect.

The restaurant app is a live-orders board. On a phone or a tablet at the counter, it shows New, Accepted, Processing and Ready lanes. Staff accept an order with a prep time, mark items 86’d until a time they pick, and there is an embedded kitchen view for the pass. For a single-station kitchen it is often the whole front-of-house system.

Printing is in the base plan. Tickets and receipts go to Bluetooth thermal printers — Sunmi, Rongta, Star, or a generic BLE printer — and to PrintNode cloud printers. A printer at the pass and the restaurant app at the counter is a complete ticket flow, and it is what most independents start with.

Your existing till can stay. If you already run Clover, Square or Toast, Devfood syncs with it two ways: menus flow in, online orders push out to the till, and webhooks keep order statuses in step. Four independent switches control the directions — app orders to POS, POS orders to the app, status updates out, terminal states only — so you decide how much of your till’s world the platform sees. You do not have to replace a till you paid for to take direct orders.

So on day one a new site has ordering on web and in the stores, a counter board, printed tickets, and, if you own one of those three tills, a synced register. That is a working restaurant.

What each add-on is for

Each is a piece of software for a specific problem. Nothing in them unlocks an ordering feature the base plan withholds, which is what keeps the single-plan promise true.

Kitchen display. A screen at the pass with per-item check-off and prep timers. It replaces paper tickets when they start getting lost — usually at the point where you have more than one station, or where the printer’s tape is the bottleneck at peak. If your tickets are not getting lost, you do not need it yet.

Self-order kiosk. A screen on the counter that shows your menu and prices, lets a walk-in sign in for rewards, adds a tip, takes card or pay-at-counter, and prints a pickup code. It is for the queue: when the line at the counter is the thing limiting throughput at lunch, a kiosk takes the order-taking off your staff. A quiet counter gains nothing from it.

POS register. A full counter register — multi-tender payments, tables and tabs, till sessions with X and Z reports. This is the one to add when your existing “till” is a cash drawer and a notebook, or when you want the counter sale and the app order in one set of books without a third-party integration. If you already run Clover, Square or Toast and the sync covers you, this is not the first thing to buy.

In-store loyalty tablet. A counter tablet that pairs with your outlet by PIN so walk-in customers can check and redeem rewards in person. It matters where walk-ins outnumber app orders and you want the loyalty wallet to work for the customer who never installs anything.

Every one of these enrols the same way — a single-use eight-character code binds the device to an outlet, staff sign in on PINs with lockout, and any device can be deactivated and its tokens revoked from the dashboard — so adding one later is an afternoon, not a project.

A decision rule that holds up

Add an in-store component when you can name the problem it solves at your counter this month, and not before.

Tickets getting lost at the pass → kitchen display.
A lunch queue out the door → kiosk.
A cash drawer and a notebook → register.
Walk-ins asking about points → loyalty tablet.
An existing Clover, Square or Toast till → none of the above; turn on the sync.

The base plan is the same product in every market and at every tier, so the day-one bill for a new site in Manila, Pune or Lagos is the base subscription for one location and nothing else. The add-ons are quoted when you ask for them, and the quote is for the piece you named.

Why it is split this way

Bundling the whole in-store suite into every subscription would make the base price carry hardware software that a delivery-only kitchen or a counter with a working till never uses. Devfood’s markets are the ones where that matters most: a value price for the four apps, and the counter suite only for the operators who run counters. The gap between the base price and a bundled one is the gap in what is bundled — it is not a discount, and there is nothing to unlock.

Starting a site

Open on the base plan with the restaurant app on a tablet and a printer at the pass. If you have a Clover, Square or Toast till, connect it during setup. Run a month. Then look at the list above and see which line describes your counter; that is the add-on to ask about, and the integrations page and the features page have the detail on each. Book a demo if you would rather see the counter board and the sync working on a live store first.

Food Courts: One Roof, One Delivery Fleet

Wed, 02 Sep 2026 00:00:00 GMT

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.

The Franchise Ladder: Per-Location Pricing

Wed, 02 Sep 2026 00:00:00 GMT

A chain’s ordering bill should fall per site as the chain grows, and it should do so on a schedule that is published rather than negotiated. That is the whole design of Devfood’s location ladder. This post sets the ladder out, explains what a franchise actually gets per outlet, and works the bill for a twelve-site chain in four currencies.

The ladder

In the United States the subscription is $79 per location per month for one to three locations. It is $69 from your fourth location and $59 from your tenth — and it is the whole account that moves, not just the new site. The day your fourth outlet opens, the first three are billed at the 4–9 rate too.

Every published market has its own row set against its own category leader (see why ordering software should not be priced by exchange rate). The same three-step shape applies in every one of them:

Market	1–3 locations	4–9 locations	10+ locations
United States	$79	$69	$59
India	₹2,100	₹1,800	₹1,575
Brazil	R$149	R$127	R$112
Philippines	₱1,156	₱982	₱867

Each figure is a month, for each location. Orders are unlimited at every step and carry no commission, so a busy outlet costs the same as a quiet one.

Billing terms are the same at every size. On monthly billing there is a one-time $299 setup fee covering app-store publishing under your brand, domain and SSL, menu import and go-live QA. Pay annually and setup is included, and you pay for ten months and get twelve.

What a franchise gets per outlet

Per-location pricing only makes sense if the outlet is a real unit in the product rather than a line on an invoice. It is, and these are the pieces a franchise operator uses:

A central menu with per-outlet overrides. Head office pushes the menu; each outlet can override prices with its own price book, adjust hours, and mark items sold out without touching anyone else’s menu. A new outlet starts from a copy of an existing one.

Franchise, zone and owner roles. Staff permissions are per outlet, and there are franchise-level and zone-level roles above them, so a regional manager sees their region and a franchisee sees their sites. The per-outlet access boundary is described on the security page: one outlet’s staff cannot read another’s orders or customers.

Per-outlet earnings. Earnings reports break out by outlet, so a franchisor settling with franchisees has the figures per site without a spreadsheet. Consolidated reporting rolls the whole network up, and the 75+ built-in reports export to CSV.

Location-based ordering and routing. The customer app routes an order to the right outlet by the customer’s location and each outlet’s delivery zones, and each outlet dispatches its own drivers — or draws on a shared pool assigned to several outlets.

Per-site devices. A single-use eight-character code enrols a printer, kiosk, register or kitchen screen to one outlet; staff sign in on PINs; a device can be deactivated remotely when a site closes or changes hands.

One brand runs across all of it — one set of colours, one app name, one loyalty wallet a customer can use at any outlet, one voucher campaign that applies network-wide or to one region.

Twelve sites, worked

A twelve-outlet chain is on the 10+ rate for every outlet.

Market	Monthly bill for 12 locations	Annual prepay (10 months)
United States	12 × $59 = $708	$7,080
India	12 × ₹1,575 = ₹18,900	₹189,000
Brazil	12 × R$112 = R$1,344	R$13,440
Philippines	12 × ₱867 = ₱10,404	₱104,040

Set that against a percentage model. A chain of that size doing, say, ₹4 lakh a month of marketplace orders per outlet at a 20% effective rate remits ₹80,000 a month per outlet — ₹9.6 lakh across the network — for the ordering channel alone. Moving a fifth of that volume to a direct channel that costs ₹18,900 for the whole network is not a close call, and the Indian break-even walks through the division if you want to replace the assumption with your own statement.

Why the whole account reprices

Two reasons, and both are about keeping the price a price rather than a negotiation.

First, the alternative — new sites at the lower rate, old sites at the old one — produces an invoice with three different unit prices on it and a franchisee asking why their site costs more than the one that opened last month. A single rate per account is legible to everyone who reads the bill.

Second, the ladder exists because a ten-outlet group takes roughly ten times the value out of the platform a single café does, and pays for it, but not ten times the price of the first outlet. The published steps are how that is expressed, and a step that applied only to marginal sites would understate it.

What the ladder does not do is discount below its own bottom step. The 10+ rate is the 10+ rate at twelve outlets and at forty; there is no further tier to ask for, and no price that is only real until you ask for a discount.

What counts as a location, for a chain

One physical outlet that takes orders. Three kitchens under one brand are three locations; a commissary preparing for the outlets, which takes no orders itself, is not one. Several counters under one roof, each taking its own orders, each count. The cloud-kitchen post works through the edge cases.

Franchising in a value market

The ladder was built for markets where a dollar price would have been the wrong price. A twelve-site chain in Brazil pays R$1,344 a month for the whole network, with native iOS and Android apps under its own brand included and multi-language storefronts included, on the same single plan a Toronto chain is on. The counter hardware — register, kitchen display, kiosk, loyalty tablet — is optional at every site and quoted separately, so a delivery-led franchise never pays for a kiosk it does not run.

The pricing page has every published market’s row. If your network spans more than one, each outlet is billed in its own market’s row, and a demo on a live multi-outlet store is the fastest way to see the roles and the per-outlet menus working before you commit a single site.

GloriaFood Is Closing: A Single-Site Plan

Wed, 02 Sep 2026 00:00:00 GMT

A large share of GloriaFood’s users were single-site independents in exactly the markets Devfood is priced for — a café in Pune, a pizzeria in Curitiba, a lechon counter in Cebu — on the free core plan, with a widget on a Facebook page and a link on WhatsApp. This post is for that restaurant. It sets out what is actually happening, what a one-location move looks like, and what it costs in your own currency.

The facts, with their sources

Two dates are in circulation, so start here.

GloriaFood is discontinued and no longer accepting new signups. Its own home page says so (gloriafood.com, checked 21 August 2026).
Full end of service is scheduled for 31 March 2027. That is Oracle’s statement — Oracle owns GloriaFood — on its public food-and-beverage page (oracle.com/food-beverage, checked 31 August 2026).
You will see 30 April 2027 elsewhere. That date comes from an earlier in-product notice. Oracle’s own current statement supersedes it, and it is the date we plan against.
There is no migration tool. Oracle has not announced an export-and-move path. Menus, customer lists and ordering links have to be rebuilt on whatever comes next.

After the service ends, widgets, order apps and links stop working. Every reorder link, QR code and bookmark pointing at GloriaFood dies with it.

What a single-site move actually involves

For one restaurant there are three jobs, and none of them is technical.

The menu is rebuilt. Send us a link to your current GloriaFood menu — a link is enough — and we set up items, modifiers, photos and delivery zones on your Devfood store. You check it; you do not type it.

You run both in parallel. Your Devfood store goes live alongside GloriaFood. You switch the link on your website and social pages, replace the QR code on the counter and the packaging, and tell regulars where the app is. No dark days; GloriaFood keeps taking orders until you are ready to turn it off.

Your regulars form a new habit. This is the part with a deadline. A customer who has bookmarked your GloriaFood link needs time to install your app or save your new link before the old one stops working, and every month you wait is a month less of that.

The rescue plan

Devfood publishes a migration price for GloriaFood restaurants, and it is set up for exactly the single-site case:

One location, at the same monthly price as the standard plan for one to three locations in your market.
Locked for 12 months from the day you start.
Setup included — menu migration, domain, go-live QA — on monthly billing as well as annual. On the standard plan setup is included only when you pay annually; the rescue plan is the one deliberate exception, because the migration is the setup and charging for it would price the rescue above what you were paying.
Zero commission and unlimited orders, as on every Devfood plan.
Includes web and app-style ordering, loyalty, and the four connected apps — customer, restaurant, driver and admin.
Excludes the native iOS and Android apps in the stores. That is the upgrade, available any time at the standard 1–3 location price for your market, and it is the thing GloriaFood’s free core never included.
Expires on 31 March 2027, with the shutdown. It is a migration price, not a discount, and a rescue price that outlived the event would quietly become the list price.

The price, in your currency

Devfood sets each market’s price against what restaurants there already pay, not by converting a dollar figure — the method is in why ordering software should not be priced by exchange rate. The rescue price per month for a single location is:

Market	Rescue price, per month
India	₹2,100
Brazil	R$149
Philippines	₱1,156
United Arab Emirates	AED 291
European Union	€67
United Kingdom	£58
Canada	C$99
Australia	A$107
United States	$79

Markets without a published row are quoted in US dollars at their band’s rate. Your customers keep paying you in your local currency through your own payment gateway, as they do today.

Is it worth it against a free plan?

The honest comparison is not “free versus ₹2,100”. It is “free until 31 March 2027, then nothing” versus a channel that keeps running. GloriaFood’s free core is ending whether or not you move; the only question is what replaces it.

Against a marketplace, the rescue price is a commission calculation. A single restaurant in India remitting 20% on ₹1 lakh a month of marketplace orders is paying ₹20,000 a month for the privilege. Moving a fraction of those regulars to a channel that costs ₹2,100 flat is arithmetic, and it is worked through in direct ordering math for an Indian restaurant if you want to plug in your own numbers.

What you gain that GloriaFood never had

The free core covered pickup and delivery ordering. The rescue plan carries, in the base subscription, the things GloriaFood sold as add-ons or did not offer at all:

Two-way POS sync with Clover, Square and Toast, if you run one of them
A driver app with auto-dispatch, plus DoorDash Drive, Uber Direct, Shipday and Nash where they operate
A loyalty wallet, cashback, vouchers and promotions
Multi-language storefronts, including right-to-left
75+ built-in reports with CSV export

And the upgrade path — your own branded apps in the App Store and Google Play — is one step away when the regulars have moved.

What to do this week

Book a demo on a live store and map your GloriaFood setup onto it: menu, order types, delivery zones.
Send the menu link. The rebuild is our job.
Pick the date you switch the links and QR codes, and give your regulars a month either side of it.

The full migration guide, with the comparison table and the form to start, is at Migrate from GloriaFood. The deadline is fixed by Oracle; the only variable is how much time your customers get to follow you.

Multi-Language Ordering Is Included

Wed, 02 Sep 2026 00:00:00 GMT

Until 31 August 2026, multi-language support on Devfood was a one-time pack that cost $499. It is now included in every subscription, at every tier and in every market. This post is about why that changed and, more usefully, what “multi-language” actually covers — because the phrase is used loosely across the industry and a buyer in Hyderabad or Dubai deserves the specifics.

Why the pack was wrong

Devfood’s pricing is set per market, and the markets it is built for — India, Brazil, the Philippines, South-East Asia, MENA, Africa — are the ones where a single-language storefront is a handicap. A Mumbai café serves customers who read Hindi, Marathi and English; a Manila counter serves Filipino and English in the same queue; a Dubai delivery kitchen needs Arabic and English on every screen, one of them right-to-left.

Selling a language pack to those customers meant charging the most for the feature in the places where it was least optional. That is backwards, so the pack went and the feature moved into the base plan alongside the native apps. Nothing on the pricing page gates it.

What is translatable

There are two halves, and they are managed separately. It helps to know which one you are looking at.

The app’s own wording. Every button, label, error message and empty state in the customer app, the restaurant app, the driver app and the counter devices. Each app has its own translation editor, organised by area and screen, and each supports CSV export and import — which is how the job actually gets done: export, send the file to a translator, import it back.

Your content. Menus, categories, items, add-ons, variants, coupons, banners, walkthrough screens, custom pages, cancellation reasons, and every notification template. These are translated where they are created rather than in a central list: each carries a language section, and you fill in the languages you have chosen.

Order notifications deserve their own line. Status updates go out by SMS, email, push and voice — plus WhatsApp — from templates you write per language, so the “your order is on its way” message arrives in the language the customer ordered in.

How the storefront behaves

You pick your languages from the full standard list and set one as primary. The primary is the fallback: anything you have not translated yet appears in the primary language rather than blank. A customer picks their language and the storefront switches — menu, checkout and notifications together, across the web storefront and the native apps.

Right-to-left languages are supported, and the apps lay out accordingly. Arabic, Hebrew, Urdu and Persian storefronts mirror the layout rather than just flipping the text direction. If you add one, look at the result on a real device before launch — RTL affects far more than text, and a screen that reads correctly with mirrored icons and a mirrored cart is the thing to check.

Rolling a language out without regretting it

Three things the operators who have done this would tell you.

Adding a language is not one job. It is the app strings, plus every piece of content you have created since launch, plus every piece you create afterwards. New content needs translating as you go, or it silently appears in the primary language for everyone else.

Translate the money-making surfaces first. Item names and descriptions, checkout, and order notifications. A customer will forgive an untranslated settings screen; they will not order from a menu they cannot read.

Do not translate everything at once. Customer app first, then the app your staff use, then the counter devices. A partly translated kiosk is worse than an English one, so finish each before starting the next.

Four markets, four shapes of the same feature

India. English as the primary, with Hindi and one regional language on the customer app. Staff apps often stay in English. The notification templates matter most here — an SMS in the customer’s own language is read; one in the wrong language is deleted.

Philippines. English and Filipino side by side, with many customers switching between them mid-sentence. A short, plain English primary with a Filipino translation of the menu covers most of it.

MENA. Arabic and English, one of them right-to-left. This is the market the RTL support exists for, and the one where checking the layout on a real device before launch is not optional.

Brazil. Portuguese as the primary, with English for tourist-heavy neighbourhoods. The Portuguese storefront is the product; the English one is a courtesy.

What is deliberately not claimed

Multi-language does not mean the platform writes your translations for you. Your content is yours to translate — that is what the CSV round trip and the per-item language sections are for — and a menu description a translator wrote will always beat one a machine guessed at. What is included is every mechanism to publish, switch and fall back between the languages you provide, on every surface a customer or a member of staff touches.

It also does not change billing currency. You are billed in your own market’s currency at a price set for that market, and your customers pay you in the currency your payment gateway settles in, as before.

Getting started

Choose your languages and a primary in the dashboard, export the customer app strings, and start with the menu. The features page lists the rest of what ships in the base plan; if you want to see a bilingual storefront switch languages live, book a demo and ask for one.

Why Ordering Software Shouldn't Be Priced by FX

Wed, 02 Sep 2026 00:00:00 GMT

The easiest way to price software for a hundred countries is to pick a US dollar figure and let the exchange rate do the rest. It is also the way to ask an Indian restaurant to pay a US price, which is what most ordering platforms quietly do. Devfood does not, and this is the method we use instead — written down so a buyer in Pune, São Paulo or Cebu can check the working.

The mistake, stated plainly

Take a US plan, multiply by the day’s exchange rate, round, and publish. The number that comes out is a fact about currency markets. It is not a fact about what a restaurant in that country pays for anything else — rent, staff, a point-of-sale system — and a software price that ignores all of those is not a price, it is an arithmetic result.

The obvious correction is to scale by income statistics instead. That fails too, and Brazil is the warning case: it is an upper-middle-income country by any World Bank table, and its restaurants pay for ordering software at roughly the level Indian restaurants do. An income multiplier would have priced Brazil like Poland. The market did not agree.

The method: anchor to the local category leader

The question that actually predicts what a restaurant will pay is what does the leading local product charge for a comparable stack? Every published Devfood row is set against that, and we record the evidence beside the number so a row can be re-derived rather than re-argued.

Markets sit in one of four bands. Each band is a multiplier on the US ladder — the US price for one to three locations is $79 per location, then $69 from the fourth site and $59 from the tenth — and the multipliers are ×1, ×0.55, ×0.35 and ×0.25:

Band	Where	1–3 sites	4–9 sites	10+ sites
A — high income	US, Canada, UK, Ireland, EU-15, Switzerland, Norway, Australia, NZ, Singapore, Japan, Korea, Israel, GCC	$79	$69	$59
B — upper Europe & Southern Cone	Poland, Czechia, Slovakia, Hungary, Romania, Bulgaria, Croatia, Slovenia, Portugal, Greece, the Baltics, Chile, Uruguay	$43	$38	$32
C — large emerging	India, Brazil, Mexico, Türkiye, South Africa, Malaysia, Thailand, Colombia, Argentina, Peru	$28	$24	$21
D — low ARPU	Philippines, Indonesia, Vietnam, Bangladesh, Pakistan, Sri Lanka, Egypt, Morocco, Nigeria, Kenya, Ghana	$20	$17	$15

Those are US-dollar equivalents. Where a market has enough local evidence to publish its own row, the pricing page quotes it in local currency; everywhere else, you are quoted in dollars at your band’s rate. Nine markets have a row today. A row is added when its band placement has local evidence, and not before — an unevidenced row is worse than an absent one.

Three markets, worked

India — band C. ₹2,100 a month for one to three locations, ₹1,800 from the fourth and ₹1,575 from the tenth. The anchor is Petpooja, the category leader, whose full POS-plus-ordering stack we recorded at ₹3,000–12,000 a month when the band was set. The whole Devfood ladder sits under the bottom of that range, with the native iOS and Android apps included. (Petpooja now lists its plans with pricing on request — checked 2 September 2026 — which is exactly why we keep the recorded figure and its date rather than a live link.)

Brazil — band C. R$149 a month for one to three locations, R$127 from the fourth and R$112 from the tenth. Goomer, the local leader, publishes its most expensive delivery plan at R$299.90 a month on monthly billing (goomer.com.br/planos, checked 2 September 2026). The whole Devfood ladder stays under it. Brazil lands in band C on that evidence, not on its income statistics.

Philippines — band D. ₱1,156 a month for one to three locations, ₱982 from the fourth and ₱867 from the tenth. The anchors recorded when the band was set were klikit’s entry plan at ₱1,499 and a rival’s ₱1,899 per outlet; klikit, like Petpooja, now quotes on request (checked 2 September 2026). The peso row is derived at a rate deliberately a little under the spot conversion, for the same reason the band exists at all.

The floor, and why the US price is $79 and not $49

There is one number the whole table is built around: no Devfood price is published below $15 a month for a location, in any band or tier. Below roughly that level the infrastructure and support behind an account stop being covered at any realistic volume, and a price that does not cover its own cost is a price that will be withdrawn later — which is worse for a customer than a slightly higher one that stays.

Band D at ten-plus locations lands exactly on that floor, and that is the constraint that sets the top of the table. A $49 US anchor would read as more aggressive, and it would put band D under cost. So the US price is $79, not because US restaurants can bear more, but because the Philippine ten-site operator has to be served at a price that survives.

What does not change between bands

The product. There is one plan, and the ladder changes the price, never the features. A Manila café on the band D row gets the same subscription a Toronto café does:

Branded ordering on web, iOS and Android, with the native app build and store publishing included
Unlimited orders with no commission and no per-order fee
Multi-language storefronts, included — a language pack for sale in a multilingual market would have been backwards
The loyalty wallet, vouchers, promotions, delivery zones, auto-dispatch and 75+ reports

The counter hardware — register, kitchen display, kiosk, loyalty tablet — is optional in every market and quoted separately, so the base price is the base price everywhere.

How to check a row yourself

Look up your market’s row on the pricing page. Then look up what the leading local product charges for its comparable plan, on that product’s own site rather than a review aggregator. If the Devfood row sits under it with the native apps included, the band is doing its job. If you think we have placed your market in the wrong band, tell us which local product you compared against — that is the evidence a row is built from, and it is the argument that moves one.

For the break-even that follows from the Indian row, see direct ordering math for an Indian restaurant.