Skip to content
Product · 5 min read

By Devfood Team who we are

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

Devfood's base plan is four connected apps; the register, kitchen display, kiosk and loyalty tablet are optional. How to decide what to add, and when.

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.

Share LinkedIn X Email

Keep Reading