A live order board the kitchen can read on a tablet you already own
Most kitchen display systems are sold as hardware, with a screen, an OS, and a contract. The screen is fine; the contract is what hurts. MobiTaste ships a browser-based kanban board that runs on a $150 Android tablet, an old iPad, or a laptop tab, with new orders arriving in seconds on a typical Wi-Fi link.
The kanban model
Orders move left to right across three columns: New, In Progress, Ready. A cook taps a card to advance it. The floor sees the same column move on the waiter view. When a ticket reaches Ready, a soft tone plays once on the floor tablet so the server can pick up.
The board groups items by station if you configure stations (espresso, grill, cold). A cook on the grill sees grill tickets; a barista on espresso sees espresso tickets. Items inside a single guest order can split across stations but stay tied to the same table token, so the floor knows where each plate belongs.
The KDS glossary entry explains the term in plain language; the features hub lists adjacent capabilities like waiter approval and call-waiter.
Why no separate device
A dedicated KDS costs anywhere from $400 to $1,500 with an installer visit, plus a monthly software fee that often exceeds the rest of your stack. The reason most restaurants buy one is locking: legacy POS vendors price the kitchen screen as the up-sell.
MobiTaste does not lock the screen. The kitchen view is a regular web page; any browser that runs Chrome, Safari, or Samsung Internet can render it. Pin the page to the home screen of an iPad and it goes full screen. Stand the tablet on a $20 holder, run it from the same Wi-Fi the rest of the restaurant uses, and the kitchen screen problem is solved.
The trade-off is hardware durability. Restaurant-grade kitchen displays are sealed against steam and grease; an iPad is not. We recommend a tablet mounted at eye level for the senior cook, with the back of the tablet away from the line. The restaurant use case covers the layout pattern.
Latency, in real numbers
New orders appear on the board in under one second on a normal Wi-Fi link, measured in May 2026 across our internal trials. The transport is WebSocket; the dashboard reconnects automatically if Wi-Fi drops for a few seconds, and queued orders fire when the link returns. The system does not lose tickets to a short network hiccup.
If your Wi-Fi coverage at the back of the kitchen is weak, the bottleneck is the access point placement, not the application. Test from the kitchen tablet’s spot before launch and adjust the AP if you see slow loads.
Roles and what they see
The kitchen role sees tickets without prices. Prices belong to the owner, the manager, and the floor; the cook does not need them. The kitchen role can advance a ticket and mark an item as out of stock, which immediately removes it from the guest menu.
The floor role sees the same board with table numbers, totals, and call-waiter rings. The owner role sees everything plus revenue.
Each staff member logs in with email and password. Argon2id hashes the password; two-factor login is on the roadmap. The audit log records role-level actions, useful when a ticket is mishandled and you want a trail.
Pairing with waiter approval
The order board and waiter approval are paired by design. Approval gates the first order from each table token; the order board displays everything else in real time. The two together cover the standard objections about QR ordering: prank prevention on the front, kitchen visibility on the back.
You can run the order board without approval (auto-approve mode), and you can run approval without the order board if you prefer paper KOTs. The standard setup uses both.
What the board does not do
It does not handle payment. Money flows through your existing card terminal or your POS. It does not handle inventory beyond the per-item availability toggle. It does not handle reservations.
It is the kitchen and floor view, not the entire restaurant. That is intentional and it is why the price point fits a single-owner cafe.
Where to go next
If you are evaluating against a POS, the pricing page has the math. If you run a full-service restaurant, the restaurant use case covers the layout and staffing pattern. For the waiter-side mechanism that pairs with this board, see waiter approval.