Projects / Case Study · Recipe-aware POS
Product I own · Live in a cafe · Sole architect & developer
Cafe POS
A recipe aware point of sale and inventory system for cafes: every sale deducts its ingredients by recipe in real time, and the terminals keep selling with no internet, then reconcile themselves the moment they reconnect. Shipped and running on CodeIgniter 4, with a Laravel and React PWA rewrite underway.
The brief
Cafes bleed money on stock they cannot see. A latte quietly spends beans, milk, a cup, and a lid, but most point of sale systems only record that a latte was sold, so the shelf and the sales report never agree. And the till has to keep working when the wifi drops, because a cafe cannot stop taking orders while it waits for a signal.
Cafe POS answers both. It knows the recipe behind every product and deducts the real ingredients on every sale, and it is built offline first so the counter never stops. One codebase runs any cafe, white label, so a new site is a setup, not a rebuild.
Architecture
Built to run fast on cheap shared hosting, with the till as the source of truth while it is offline.
The target is a plain cPanel host with no daemons, no Redis, and no websockets, so nothing depends on infrastructure a small cafe will not pay for. Background work runs on the database queue driven by a single cron, and the front end ships as a static build. The rewrite keeps the same constraints: a Laravel API with cookie based auth and a React progressive web app the terminals install like a native till.
Selling with no internet
The core product decision: the till must keep selling with the internet down, and sort itself out later with nobody pressing sync.
Sales made offline are stored on the device and sync automatically the moment connectivity returns. Every write carries an idempotency key, so orders, payments, stock deductions, and receipts reconcile server side exactly once no matter how many times a flaky connection retries. A staff member never sees a spinner and never picks which copy is right. The till just works, and the numbers agree when the dust settles.
Recipe-aware inventory
The engine at the heart of it turns a sale into stock movements, not just a line on a receipt.
Recipe deduction
Each product maps to a recipe of ingredients, so selling it draws down the real stock behind it, down to the cup and the syrup pump.
FEFO stock
Inventory is consumed first expired, first out, so the shelf and the system waste less and agree more.
Modifiers & pricing
Add a shot, swap the milk, size up: modifiers adjust both the price and the ingredients deducted.
Refunds & Z-read
Refunds reverse the stock movements too, and an end of day Z-read closes the till with numbers that tie out.
Engineering & quality
Money is never a float, writes are idempotent, and a test suite pins down the behaviour that has to stay correct.
The shipped build carries a real test suite that defines the correct behaviour of the deduction engine, modifier pricing, FEFO consumption, refunds, and the Z-read, so a change that breaks the maths fails loudly instead of quietly costing the cafe money. The Laravel and React rewrite ports those scenarios one for one and has to match the same results before it can replace anything.
Need a till that keeps selling offline?
I build offline first point of sale and inventory systems that reconcile themselves and tie stock to real recipes, end to end. If that is the build you are scoping, let us talk.