Restaurant software has a problem that nobody talks about loudly enough. Most of it was built in pieces, by different vendors, at different times, with no shared logic between them. Your POS doesn't talk to your inventory system. Your kiosk runs on different data than your kitchen display. Your head office dashboard pulls numbers that are already four hours old. You end up with a stack of tools held together by manual processes, staff workarounds, and a spreadsheet someone updates every Monday morning.
We built Doyfood because we wanted to solve this properly. Not with another integration layer on top of existing broken systems. With a single unified platform — one codebase, one data model, one source of truth — that handles everything from the customer-facing kiosk to the head office management dashboard. And we're running it live in Dubai and France.
Here's what we built and how it works.
The Architecture: Two Engines, One System
Doyfood is split into two primary systems that operate in tandem.
The first is the RMS — Restaurant Management System. This is the headquarters layer. It handles master data: menus, pricing, product configurations, business-wide analytics, and anything that needs to be consistent across every location. If you run five branches and you change the price of a menu item, you change it once in the RMS and it propagates. Managers get a centralised dashboard that gives them a real view of the business, not a delayed one.
The second is the OMS — Order Management System. This is the in-store operational layer. It handles the full lifecycle of every order from the moment a customer places it to the moment it leaves the kitchen. It runs locally, which matters — a cloud dependency failure shouldn't stop your restaurant from taking orders.
The OMS is where most of the surface area is. It powers four distinct interfaces: the Admin panel for store managers, the Kiosk for customer self-service, the POS for staff handling walk-in and counter orders, and the backend that ties all of it together with real-time order processing.
These two engines — RMS and OMS — communicate, but they're also independently functional. The OMS can operate without a live connection to RMS. This is a deliberate architectural decision, and it's one of the things that makes Doyfood practical in real restaurant environments rather than just in demo conditions.
The Kiosk: What We Actually Built
The kiosk is the most visible part of Doyfood and the piece that required the most care to get right.
A kiosk in a restaurant context has a specific problem: it is used by everyone. A tourist in Dubai who doesn't speak Arabic. A regular customer who knows exactly what they want and will be annoyed if the interface is slow. A child who wanders over while a parent is distracted. The interface has to work for all of them, in seconds, without staff intervention.
Most kiosks on the market look like they were designed by the same team that designed the ATM you use at the airport. The UI is functional in the narrow sense — it accepts input — but it's not fast, it's not pleasant, and it doesn't reflect the brand of the restaurant running it. They're generic terminals dressed up with a logo.
We built the Doyfood kiosk to be something different. The interface runs on React 19 with Tailwind CSS 4 and Framer Motion handling the animations. The result is an experience that feels closer to a well-designed consumer app than a transactional terminal. Menus load fast. Customisation flows are clear. The order confirmation is immediate and unambiguous.
The kiosk connects directly to the OMS backend via WebSocket, which means the moment an order is placed it's in the system — no polling, no delay, no gap between what the customer sees and what the kitchen receives.
The POS: Built for Staff, Not for Demos
A POS system is used by people who are on their feet for eight-hour shifts and will interact with it hundreds of times a day. The design bar is different from a consumer app. Speed matters more than aesthetics. Errors need to be recoverable in two taps. The cognitive load at 1pm on a Saturday when the queue is ten people deep needs to be as low as possible.
The Doyfood POS is built with this in mind. The interface is high-performance — Bun as the runtime, Hono as the backend framework, TanStack Query handling data synchronisation on the frontend. The practical result is that the POS is fast in a way that matters operationally: order entry is quick, modifications are quick, and the transition from one order to the next has no lag.
It also shares the same OMS backend as the kiosk. An order placed at the kiosk and an order placed by a staff member on the POS enter the same queue, get processed by the same logic, and reach the kitchen through the same pipeline. There's no separate system to reconcile at end of day.
Why Dubai and France
These are not two markets that obviously belong together, but for Doyfood they make sense as a starting point for specific reasons.
Dubai is a city where restaurant density is extraordinarily high, customer expectations around technology are also high, and the turnover rate for food businesses creates a consistent demand for operational infrastructure that actually works. The kiosk market here is growing — partly because of labour considerations, partly because customers in Dubai are genuinely comfortable with self-service technology in a way that some other markets are not yet.
France is a different kind of challenge. The restaurant culture is older and the integration of technology into the dining experience is more contested. But the operational problems are the same. Disconnected systems, manual reconciliation, and POS software that was last meaningfully updated when flat design was still controversial. There's a real market for a system that's modern, fast, and actually integrated — it just requires a different sales conversation than Dubai.
Running in both markets also forces the system to handle real-world complexity: different currencies, different tax structures, different languages at the kiosk interface. These are not hypothetical edge cases. They're in production.
The Stack and Why We Chose It
The technical choices behind Doyfood were made with operational performance and developer velocity in mind, not trend-following.
Bun is the runtime across all backend services. The performance improvement over Node.js is real and measurable — faster cold starts, faster package installation, lower memory overhead. For a system that needs to handle real-time order processing in a busy restaurant, this matters.
Hono is the backend framework. It's lightweight, fast, and runs on Bun without friction. We didn't need the full weight of a larger framework. Hono gives us what we need and gets out of the way.
Drizzle ORM handles the database layer over Postgres. The schema management is clean, the type safety with Zod is tight, and Drizzle Studio gives us a visual database explorer that's been useful during both development and debugging in production environments.
On the frontend, React 19 with Tailwind CSS 4 and Framer Motion gives us the combination of performance and interface quality the kiosk and POS require. TanStack Query handles server state across all frontend applications with a consistency that makes the codebase easier to reason about.
WebSocket is used throughout for real-time communication between the kiosk, POS, and kitchen-facing systems. An order placed at a kiosk needs to appear in the kitchen in under a second. Polling doesn't meet that bar. WebSocket does.
The entire system is structured as a monorepo — one repository containing the RMS backend, RMS frontend, OMS backend, OMS admin, OMS kiosk, and OMS POS. This is a deliberate choice. Shared types, shared validation logic, and shared tooling across all six applications. When we update the data model, we update it once. When we run typechecks, we run them across everything.
What This Changes for Restaurant Operators
The practical case for a system like Doyfood isn't complicated. If you're running a restaurant today and you have a POS from one vendor, a kiosk from another, a management dashboard from a third, and you're spending two hours every week reconciling data between them — that's not a technology problem. That's an architecture problem. And the solution isn't another integration. It's a system that was built as one thing from the start.
Doyfood is that system. The kiosk, the POS, the store management layer, and the head office dashboard all run on the same data model, updated in real time, without manual reconciliation. A menu change made at HQ reflects on every kiosk and POS terminal immediately. An order placed at a kiosk is in the kitchen queue before the customer has picked up their receipt.
We're live. We're running in Dubai and France. And we're building the next layer.
Running a restaurant and tired of software that doesn't keep up?
Doyfood is a full-stack restaurant management ecosystem built for modern food businesses. Get in touch to learn more.
