One complete restaurant system — from order to accounting entry.

At a glance

The work, step by step

1. 01

   The problem

   A restaurant does not lose money on slow nights. It loses it in the gaps: the cashier records the sale, the inventory lives in an Excel file someone updates when they find the time, reservations sit in a notebook at the host stand, and at month end the accountant sits down and re-enters the entire month by hand. Each piece works fine on its own, but yesterday's dish never came off inventory, and nobody knows the difference between the count and the books until closing, by which point it is too late to see which day the margin slipped.

   Specialised systems solve one piece and stop at its edge. The problem is not a missing program; it is that a single order has to pass through four places before it becomes a number anyone can trust, and every one of those places waits for a person to carry it to the next.

2. 02

   What was built

   I built S12 as one system covering the whole loop: point of sale, kitchen display, floor management and reservations, inventory tied to recipes that deduct on every sale so a dish's cost and margin appear without anyone typing a number, a self-service kiosk and a QR store the guest orders from directly, and a double-entry ledger that posts its entry automatically with every operational event. Each restaurant sits on its own subdomain with its own package, branches and branding, all running from one codebase: 211 database tables, 282 UI components, 182,000 lines of PHP, four complete languages with their fonts, and zero JavaScript runtime dependency.

   The decision that shaped the build was to have every operational event post its accounting entry at the moment it happens rather than in a nightly batch. The original pain was an accountant re-entering the month, and a nightly batch would only have moved that manual work from month end to the next morning. The second was to render every screen on the server with no runtime JavaScript, because a point of sale runs on an old device and a connection that can drop mid-order, and that is the one moment where a cashier cannot wait for a bundle to load in the browser.

3. 03

   The result

   182,000 lines of Laravel PHP

   I am not putting a number here that I did not measure. What the project set out to move comes down to three things: the accountant's month-end closing time, the gap between counted stock and the balance the system expects, and the delay between an order being placed and its cost and margin showing up in front of the owner. The first should approach zero because every sale, purchase and adjustment carries its journal entry the moment it happens; the second is the gap that used to surface late in the month and change nothing. These are the agreed measures, not results I have measured yet.