Restaurant management built around the kitchen pass Seven modules, one order record, one login

Home/Platform

The loop under everything

One order record. Four movements. No exports in between.

Most restaurant software is a billing product with other things bolted to the side. Dearrasa starts from the object that matters, the order, and follows it from the moment it is taken to the moment it changes what you buy tomorrow.

Walk through it with us See the seven modules

The loop

From order source to owner dashboard, in one direction.

Each stage writes to the same record rather than passing a copy along. That is the whole design decision, and everything else on this site follows from it.

Stage 01

Order source

Counter terminal, captain tablet, QR menu at the table, or a delivery aggregator feed. All of them create the same order object with the same fields.

Stage 02

Kitchen display

The order splits into station tickets and starts timing. Nothing is printed unless you want paper as a backup, and reprints never create a second record.

Stage 03

Inventory ledger

Firing a dish posts its recipe against stock. Voids and cancellations reverse cleanly, so the ledger is a record of what happened, not what was intended.

Stage 04

Forecasting engine

Consumption and sales history train a demand model per outlet. Output is prep quantity, indent quantity and suggested staffing, not a vague score.

Stage 05

Owner dashboard

Sales, cost of goods, wastage variance, labour cost and turn time in one view, per outlet and consolidated, for the period you actually think in.

Why it holds together

One menu. One recipe book. One stock ledger. One set of permissions.

Changed once, live everywhere

Edit a price, mark an item unavailable, or change a portion size, and the counter, the captain tablet, the QR menu and the aggregator listing all reflect it. A dish that runs out is taken off sale the moment stock hits its floor, which is the only reliable way to stop a table ordering something the kitchen cannot cook.

Recipes

The bridge between selling and buying

A recipe is not documentation in Dearrasa, it is the mechanism. It carries ingredient quantities, expected yield and a wastage allowance, and it is what turns a sale into a stock movement and a cost figure. Sub recipes are supported, so a gravy base prepared in the morning is costed once and consumed by the six dishes built on it.

Ledger

Append only, so variance is provable

Stock movements are entries, not overwrites. Receipts, transfers between outlets, consumption from the pass, staff meals, wastage and physical count adjustments each land as their own line with a user against it. When the counted figure and the ledger figure disagree, you can see precisely where the two paths separated.

Identity

One login, scoped by role and outlet

A cashier, a station cook, a floor manager, a purchase manager and an owner see very different screens from the same account model. Rights are scoped to outlet as well as function, so an outlet manager in one location cannot pull margin reports for another.

Stated honestly

What happens when the internet drops mid service.

This is the first question any restaurant owner should ask a software vendor, and the answer is usually vague. Here is ours, with the limits included.

Service keeps running

The counter and the kitchen display hold the current shift locally. Orders can be taken, fired, timed, modified and billed with no connection at all. Printing to a local thermal printer is on the same local path, so KOTs and bills do not depend on the cloud either.

It reconciles when the line returns

Every local action carries a device identifier and a timestamp, and syncs in order once connectivity is back. Stock consumption, payments and timing data all post with their original times, so a two hour outage does not distort the day's report.

What genuinely does not work offline

Aggregator orders cannot reach you without a connection, because they arrive over the internet by definition. Cross outlet views, freshly generated forecasts and card or UPI authorisation also need the line up. We would rather tell you that now than have you discover it on a Saturday.

Who sees what

The same service, read five different ways.

Station cook

Only the tickets for this station

Item, quantity, modifiers, timer. No prices, no guest data, no menu editing. Large type, high contrast, usable with flour on your hands.

Cashier

Take orders, take payment, close bills

Discounts above a set limit need a manager code. Voids after a KOT is fired are logged with a reason against the user.

Floor manager

The whole floor and the whole pass

Table states, waitlist, delayed tickets, staff on shift, and the authority to approve discounts, reprints and comps.

Chef or purchase

Recipes, stock, indents, wastage

Cost per plate, supplier rates, variance against the ledger, and the prep sheet the forecast produced for tomorrow.

Owner

Money, across every outlet

Sales, cost of goods, labour, wastage and turn time consolidated, plus the ability to drill into any single bill that looks wrong.

Every role

Logged, not assumed

Price changes, comps, voids, stock adjustments and permission changes carry a user and a timestamp. See Security for the detail.

Next service

See the loop run on your own menu.

Send us a handful of your dishes and we will build them as real recipes, fire them through a live pass, and show you the stock movement and cost per plate that comes out the other side.

Talk to us Sign up