Ordering and delivery
Menus, orders, kitchen and dispatch as one flow — an order placed online arriving where it is cooked, in a state the kitchen can act on, with the customer told the truth about when it will reach them.
Talk about scopeThe kitchen is the constraint, and it cannot queue
Every other system we build can make a user wait. This one cannot: food starts degrading the moment it is cooked, a rider is idle or late, and an order accepted at the wrong moment is a bad meal rather than a slow page. That makes capacity the central object — how many orders a kitchen can genuinely hold at once, whether to accept the next one, and what to tell the customer when the honest answer is forty minutes. Systems that model ordering as a shopping cart with a submit button get this wrong in the only way that matters.
The vertical rule is what the kitchen can actually hold. The question the software has to answer at 19:30 is not whether the customer may order — it is whether to say forty minutes, and mean it.
What we would build
An order is a state machine, not a record
Placed, accepted, cooking, ready, collected, delivered — and at every one of those points it can be cancelled, refunded, part-refunded or remade, sometimes by the customer and sometimes by the kitchen. Each transition needs a time and a name against it, because the arguments afterwards are always about which of those happened and when.
- Accepted, with a promise the kitchen can actually keep
- Cooking, and visible on a screen someone is watching
- Ready, and waiting on collection rather than on nobody
- Delivered, or failed for a reason that was recorded
Menus change faster than anyone expects
Items sell out mid-service, prices differ between delivery and the counter, and a modifier that is free on one item costs money on another. The menu is a versioned, time-bound structure rather than a list — and an order placed an hour ago has to keep pricing itself against the menu that existed when it was placed, not the one on the screen now.
Owning the channel, not renting it
The usual reason a restaurant commissions its own ordering is margin: the aggregators take a percentage that turns a thin business into a losing one. That sets a hard test for what we build — it has to be good enough that a customer chooses it over an app they already have installed, or the commission is simply replaced by a build cost.
When not to build this
A packaged product is the right answer more often than a development company usually admits, and if your problem is an ordinary one that something off the shelf already solves, we will tell you so rather than quote for it. What follows is the case for the other answer — the conditions under which building is worth what it costs.
The workaround has become the process
A packaged system that mostly fits leaves a residue — the spreadsheet kept alongside it, the step done by hand every month, the field used to mean something it was not named for. When that residue is where the actual work happens, you are already maintaining custom software, just without any of the benefits of having built it.
The thing you do differently is the thing it cannot do
Every business has a few processes that are genuinely its own, and those are usually the ones it competes on. Off-the-shelf software is built for the average of a sector, so it handles the ordinary parts well and the distinctive part not at all. Building is worth it exactly where that overlap fails, and rarely anywhere else.
A vulnerability shared by every deployment
A vulnerability in a packaged product is a vulnerability in every deployment of it, and attackers only have to find it once. A system built for one business is not on that list.