Company | Dearrasa

Where this came from

The problem was never a lack of software.

Walk into almost any busy restaurant in this country at nine on a Saturday and you will find competent people running an operation on memory. The captain knows which table is waiting. The tandoor knows which order came first. The cashier knows which bill has a discount on it because the owner waved at them. Somebody in the back knows that the paneer will not last until closing.

None of that knowledge is written down anywhere. It lives in five heads for the length of a shift and then it evaporates. The next morning the owner sits with a stack of dockets, a spreadsheet that was last honest three weeks ago, and a bank statement, and tries to reconstruct what happened. The gap between those three things is where the margin went, and it is almost never recoverable after the fact.

The software that exists mostly makes this worse rather than better. A billing product with an inventory tab that nobody fills in. A separate kitchen display that receives a copy of an order rather than the order itself. A reporting dashboard that produces a chart nobody can act on because the underlying food cost was typed in by hand months ago. Each piece works. Together they contradict each other, and every contradiction costs somebody an argument.

So we started from the pass, and worked outwards.

The kitchen pass is the one place in a restaurant where time is physically visible. Tickets arrive, they sit, they go out. Anyone standing there can see the whole state of the service at a glance. We took that as the shape of the software rather than as one screen inside it. An order is a single record that moves along a rail, and billing, stock, staffing and forecasting are all views onto the same movement rather than separate systems exchanging copies.

That decision is why the inventory in Dearrasa is accurate without anyone maintaining it, why a forecast can be expressed as a prep quantity rather than a chart, and why the site you are reading is built around a rail of tickets instead of a grid of feature cards.

What we hold to

Three principles, and what each one costs us.

Principles are only real when they rule something out. Here is what each of ours prevents us from doing.

Principle 01

Built for service speed, not for back office reports

Every feature is judged by whether it slows down a live service. If a screen needs a confirmation dialog during a rush, it is a bad screen. If a report requires a cook to enter something extra, the report loses.

What it costs us: we have turned down data capture that would make certain analytics richer, because the person who would have to enter it is holding a pan.

Principle 02

Every ingredient tracked, nothing guessed

Numbers we show are traceable to a recorded movement or a stated model input. Where a figure is a forecast, it says so and shows what it was built from. Where our accuracy is poor, the product tells you rather than rounding towards confidence.

What it costs us: our forecasting screens are less impressive in a demo than software that presents an assured number for a restaurant it knows nothing about.

Principle 03

Works even when the internet does not

A restaurant cannot stop taking orders because a line went down. The counter and the pass hold the shift locally and reconcile afterwards, and we state clearly which functions genuinely cannot work offline instead of implying everything does.

What it costs us: a significantly harder engineering problem than a purely cloud product, and a longer path to some features.

How we prefer to be judged

There are no testimonials on this site, and that is deliberate.

A wall of quotations proves very little, and a logo grid proves less. We would rather you formed a view from two things: whether the live rail on this site behaves like a real kitchen display, and whether the module pages describe your problem accurately enough that we have clearly stood in a kitchen.

Fire a test order Read the modules

What we will tell you in a conversation

Where we are weaker than an incumbent. There are mature products in this market with features we do not have yet, and we will name them.
When you should buy less. If two modules solve your problem, we will quote two modules.
When you are not a fit. Some operations are better served by something simpler than Dearrasa, and telling you that costs us less than an unhappy customer.
What our real numbers are. During a pilot we measure ticket times and forecast accuracy on your floor and report them as they came out.

Rasa means taste, and also essence. Both meanings are the point.