Restaurant and Cafe Software: What We Learned Building Our Own Product

A restaurant's evening moves fast and forgives nothing. At half past seven the floor fills up; a waiter is covering three tables at once, the kitchen is racing to keep up, the takeaway phone keeps ringing, and a couple is waiting at the till to pay. At this tempo, software that slows down, freezes, or lets two screens fall out of sync translates directly into a plate going cold, an order being forgotten, a courier waiting at the door. If an accounting package produces a report five seconds late, nobody notices; if the tab screen opens five seconds late, the whole floor notices.

The second difficulty is that this tempo is not experienced by one person but by very different roles. The waiter is at the table, the cook at the stove, the cashier at the till, the courier on the road, and the owner is often in another city. All of them need to see the same truth at the same moment: which table is occupied, which order is in the kitchen, which tab is open. Yet the common picture in the industry is the opposite — a POS program, a QR menu bought separately, a third-party delivery app and stock tracked on paper. The gaps between these disconnected pieces get filled, every single day, by human labour.

We are writing this piece not as observers but as a team that has lived inside this problem. We built — and are still building — Horeca, a multi-tenant operating platform for cafes, restaurants and similar venues, from scratch. Below, we will put the sector's software needs into a framework, and then walk step by step through how we implemented each part of that framework in our own product, where we struggled, and what we deliberately postponed.

"Restaurant software" is not a single product; it is a family. Its most visible member is the point of sale — POS and the tab: the layer where orders are taken, bills are kept and payments are recorded. Right next to it sits the digital menu — opened from a QR code on the table, with prices and items that can be updated at any moment. On the kitchen side there is the KDS (kitchen display system): tickets land on a screen instead of paper, and everyone can see how long each order has been waiting. In the background runs the inventory and recipe layer: which product consumes how much of which ingredient, and what cost and margin really are. On top of all this sits reporting: the photograph of the day, the week, the branch.

Then there is the guest side of the business, which the industry usually calls 'engagement': reservations, calling a waiter, paying at the table, loyalty programs, gift cards, campaigns. These look less vital than the POS core, but this layer — the relationship the guest builds through their phone — is very often what sets one venue apart from another.

The typical path in the market is to buy each member of this family from a different vendor. In the short term this even makes sense: each piece is good at its own job. The long-term price is that integration becomes your problem. Orders from the QR menu are re-typed into the POS; the inventory program never hears about the sale; the loyalty app cannot see the tab. We built Horeca on a single core precisely to remove that price: all of these layers live on the same database, the same business rules and the same real-time flow.

The first decision we made when translating a venue's operation into software was this: screens must be steps of one flow, not separate programs. The waiter opening the table, the cook at the stove, the tab at the till and the courier on the road all live the same moment, and the software has to model it that way. In Horeca an order passes through a single lifecycle: it starts as pending, gets confirmed or rejected, lands in the kitchen, is prepared, is delivered, and closes with payment. Every link of that chain appears on a different role's screen, but the chain is one — and we verified this flow end to end, on real devices.

The natural consequence of that decision was one app per role. We call the business panel Desk: menu, floor plan, inventory, staff, reports — the owner's and the manager's desk. The app in the waiter's hand is Floor: tables, orders, service calls, their shift. The kitchen screen is Flame: a paperless ticket flow. At the till there is Till: collection and closing the tab. Beam drives the TVs in the window; the delivery courier works with Route. Behind all of them stands a single API and a single truth.

Real-time here is not decoration; it is a requirement. The second a waiter sends an order it must appear on the kitchen display; the moment the kitchen says 'ready', the waiter's phone should buzz. We solved this with a combination of WebSocket-based live connections and mobile push notifications. During the evening rush, nobody should be pressing 'refresh' between screens — the flow has to flow by itself.

The heart of the sector is the tab, and a tab is a far more complicated object than it looks. Four people sit at a table; two pay together, one wants to split out their own items, one pays by card. A treat from the house gets added, one item is returned, a discount is applied to half of the bill. As service ends a tip is left, and that tip has to be distributed fairly across the shift's team. All of this must live inside the same tab, consistently.

That is why, in Horeca, payments attach to individual items rather than to the tab as a whole: who paid for what is explicit at the record level. Splitting the bill, treats and discounts are not after-the-fact corrections but natural movements of the tab. Tips carry their own model and are stored together with their distribution rule. Where money is involved there is no such thing as 'approximately correct'; so we write the critical records on the payment side using a transactional outbox pattern that preserves consistency even if something crashes mid-way. At the end of the day, the number in the till and the number in the system must be equal — not close.

Pay-at-table is part of the same anatomy: a guest can pick their own items on their phone and settle their share without waiting for the waiter. This is a direct gift of the item-level payment model — when the architecture is right from the start, higher-level features arrive without force.

From the outside a menu looks like a list; from the inside it is a data model. Categories, products, product variants (small/medium/large), option groups (extra cheese, less sugar, choice of sauce)... In Horeca the menu is modelled with this structure and managed in one place: a price change made in Desk is reflected simultaneously on the table's QR menu, the waiter's Floor screen and the Till at the register. For businesses whose menus already exist elsewhere, bulk menu import was solved as its own topic — nobody should have to re-type a hundred and fifty products by hand.

Beneath the menu lies the sector's most neglected layer: the recipe. Behind every product stands a bill of materials — which ingredient, how much. Once recipes are defined, three things happen by themselves: stock is depleted when a sale happens, the product's true cost is computed, and the question 'does this item actually make money?' stops being a guess. In Horeca, stock items, stock movements and recipe lines build this chain, and cost reporting sits on top of it.

The reason we put this layer at the centre of the product is simple: in food and beverage, revenue is plentiful and profit is thin. A business already knows its revenue from its till; what it does not know is which product inside that revenue carries the margin and which one silently loses money. That is exactly where software's job begins.

First, concurrency. At peak hour two waiters can add items to the same table at the same moment; the kitchen updates a status while the till starts splitting the bill. None of these collisions may surface to the user as an 'error', and the data must never end up inconsistent. This is why we defined the order lifecycle with strict state transitions and use a transactional queue on the money side.

Second, staff turnover. Teams change often in this sector; if learning the software takes longer than an afternoon, the software is designed wrong. This is one more reason for the one-app-per-role decision: the waiter sees only the waiter's screen, the cashier only the till's. Nobody gets lost among forty menus they will never use.

Third, multi-tenancy. If hundreds of businesses that know nothing of each other are to live on the same system, data isolation is not a feature but a condition of existence. In Horeca every business record belongs to an organization, and the tenant hierarchy follows the real world: an organization, brands beneath it, branches beneath the brands. A single-cafe operation is comfortable inside this model, and so is a multi-brand group.

Fourth, device reality. In the field you meet every brand of tablet, phone and TV. This diversity is why we wrote the operational apps in Flutter: the same code base runs on the waiter's Android phone, the kitchen's tablet and the TV in the window. The panels we kept on the web (Angular) — an owner must be able to open a report from anywhere.

Let us take an honest photograph at this point. The core of Horeca stands today: a single API on .NET 9, more than sixty business tables on PostgreSQL, close to a hundred controllers serving eight client endpoints. The main flow — from QR menu to order, kitchen to payment and tab closure — has been tested end to end on real devices. The two management panels — Desk for businesses, Orbit for the platform operator — are substantial; Floor is our most mature mobile app in the field, with Flame, Till, Beam and Route following it.

Around the core sits a wide ring of modules, and that ring is actively growing: reservations, catering, waiter calls, valet, loyalty programs, gift cards, suspended items, campaigns, birthdays, a WiFi welcome portal, music requests, cross-table treats, a social wall... Each of these lives in the system with its own data model and screens. In the last three weeks alone, dozens of dated database migrations landed — delivery, catering, loyalty, gift cards and cost accounting among them. We do not call it a 'finished product'; we call it a production-ready core with an expanding ecosystem on top.

In the same honesty, let us also say what is not there yet: external payment gateway integrations, e-invoicing and receipt printer connections are not in the code today; they sit on the roadmap. In a promotional piece it would be easy to present these as done — but we prefer to be able to point at the code behind every sentence we sell.

A neighbourhood coffee shop and a multi-floor hotel restaurant cannot use the same software — or rather, they should not. The coffee shop has no need for a valet module, the hotel none for suspended coffee. But their core is identical: menu, orders, payments, stock. To resolve this tension we built Horeca capability-driven: a module catalogue lives in the system, every module has a recommended mapping per venue type, and a business switches modules on and off per branch.

In practice it looks like this: when adding a kebab house, a cocktail bar or a hotel breakfast room, you pick one of twelve venue types; the matrix proposes the module set that makes sense for that type, and you refine it to taste. At runtime no code ever asks 'is this venue a kebab house?'; it only knows which capabilities are switched on. Adding a new venue type therefore never requires touching the core.

Above the modules sits the subscription layer: business subscriptions and their invoices are managed on the platform side. In an interesting symmetry, the same infrastructure lets businesses sell subscriptions to their own customers — like a monthly coffee subscription at the neighbourhood cafe. The architectural decisions you make while building a multi-tenant platform sometimes seep into your tenants' own business models; it is one of the most enjoyable side effects of this work.

So far we have looked from inside the business; now let us look from the table. A guest sits down, scans the code on the table and the menu opens — no app download, no sign-up. They order; the order drops straight into the kitchen's flow. When they need something they call the waiter from the screen, and the call routes to the right waiter on Floor. When leaving, they can wait for the waiter — or pick their own items and pay from their phone.

On top of this basic flow comes an experience layer that opens up according to the venue's character: birthday surprises, music requests that give guests a say in the playlist, sending a treat to another table, suspended coffee, a social wall, a WiFi welcome page... These are modules that rarely make it onto the agenda of POS vendors; they made it onto ours because a venue is not a cash register — it is a social experience. Loyalty programs, gift cards and campaigns are the parts of the same layer that build a lasting relationship.

The technically critical point is this: the entire guest side uses the same core as the business side. The product on the QR menu is the product defined in Desk; the bill paid at the table is the tab that Till sees. The guest experience is not a separate product — it is the other end of the same flow.

Orders in a modern food-and-beverage business no longer come only from the table. The same kitchen simultaneously feeds the tab on the floor, the takeaway order and the delivery run. To model this we kept 'how the order will be fulfilled' as its own concept: the same order object can flow as table service, takeaway or courier delivery. From the kitchen's point of view nothing changes — the ticket lands on the same screen; what changes is only whether the order leaves through the floor or through the door.

The courier side has its own app: Route. The courier sees their deliveries, addresses and earnings on their phone; the business tracks which package is on the road and which has been delivered from inside the same system as the tab. For businesses paying commission to third-party food platforms, this means being able to run their own delivery channel on their own software — the order, the customer and the data stay with the business.

The off-floor flow has two more members. Reservations live on top of the floor plan: which table, what time, how many guests. Catering, meanwhile, is a small order world of its own — kept in a separate model with its lines, delivery date and amount; trying to squeeze a hundred-person event order into the evening service's tab flow breaks both flows. Making these separations early keeps each flow true to its own nature.

Service ends, the floor empties, and one question remains: what actually happened today? In a system built on recipe costing, item-level payments and a single flow, the answer to that question is not arithmetic — it is a natural output. The dashboard in Desk shows the day's revenue, order distribution and open tabs live; the platform operator watches the health of all tenants from Orbit. The numbers come from the flow itself, not from the till — which is why there is no end-of-day 'the till doesn't match the system' meeting.

One step beyond reporting is forecasting. As sales history accumulates, the system can draw a heat map of busyness by day of week and hour, and produce demand forecasts for the days ahead. This moves the question 'how many staff do I schedule for Tuesday evening, how much stock do I buy' from intuition to data. The staff performance report is another slice of the same data: who covered how many tables, how each shift went — together with tip distribution, a fair picture.

In multi-branch businesses the real value of reporting emerges in its centrality. Thanks to the organization–brand–branch hierarchy, the owner compares all branches on a single screen: which branch is strong in which product, whose costs have drifted. Opening the second branch is not a new installation on the software side but a new row under the same organization — and the reports cover that row automatically.

Step one is discovery and setup design: we listen to the venue's flow — how many rooms, how many tables, is there delivery, how is the kitchen split? The venue type is chosen and the module set narrowed accordingly. Step two is menu and floor setup: categories, products, variants, recipes and the floor plan go into the system; an existing menu is migrated with bulk import.

Step three is roles and devices: team members are defined; Floor goes to the waiters, Flame to the kitchen, Till to the register, Beam to the window; QR codes go onto the tables. Step four is team training — which, thanks to the one-screen-per-role principle, is usually the shortest step of all: everyone learns only their own screen.

Step five is go-live and monitoring: the first services are watched closely, friction in the flow is removed on the spot, and reports are confirmed to be flowing correctly. From then on it is a living relationship between the venue and the platform: new modules are switched on as needs arise, the menu is updated when the seasonal card arrives, and when the second branch opens it is added under the same organization. Software here is not something installed and left behind; it lives with the business — which is, after all, the real promise of the SaaS model.

Without turning this piece into a shopping guide, here are the questions we personally saw matter during our own development. One: do the QR menu, POS, kitchen and inventory live on one core, or is integration your problem? Two: are payments stored per item — bill splitting and pay-at-table depend on it. Three: is there recipe and cost tracking, or is the 'inventory module' just a counting ledger?

Four: do the waiter's and the kitchen's screens update in real time, or is somebody pressing 'refresh'? Five: how long does it take to teach the software to a new hire? Six: when the second branch opens, is the model ready for it — or does it mean a second installation? Seven: are you paying for features you never use, or is the structure modular?

None of these seven are marketing questions; they are all architecture questions. Their answers hide not in the brochure but in the product's data model. We built Horeca to be able to answer yes to them — and wherever we cannot yet say yes, we said so plainly above.

Food-and-beverage software is one of the most unforgiving test environments of any industry: the evening service pardons neither your architectural debt nor a half-thought-out flow. The clearest thing we learned building Horeca is this: in this sector, good software is not feature-rich software — it is single-flow software. The hand that opens the table, the hand that fires the stove and the hand that closes the bill must see the same truth; everything else is built on top of that.

If you are looking for a system for your own venue, or want to discuss a software idea for this sector, our door is open: the first conversation is non-binding, and you will be talking not to a sales team but to the team that wrote this product.