Liquor Management System
A prepaid liquor wallet for shops and their customers
A multi-tenant platform where a customer holds a prepaid balance of alcohol, measured in millilitres, at each shop they are enrolled with. Shop owners draw it down, customers approve every deduction, and both sides get an audit trail.
The problem
Shops were tracking prepaid customer balances on paper and in spreadsheets. Nothing reconciled: a customer could not prove what they had left, a shop could not prove what had been drawn, and a disputed figure had no history behind it. Any system that replaced it had to be trusted by both sides of the counter, which meant no balance could move on one party’s word alone.
What we built
01One ledger, no side doors
Every balance change runs through a single ledger service inside a database transaction that also writes the matching transaction row. No other code path can touch a balance, so the numbers and their history cannot drift apart.
02Approval in both directions
A customer requests credit and the shop owner approves it; the shop owner records consumption and the customer approves that. Each request is claimed atomically, so two approvals of the same request resolve once and the second is told it is already handled.
03Authorisation checked per resource
A role in the token is never enough. Every shop-scoped request re-proves that the shop belongs to the caller, and enrollment between a customer and a shop is its own gate, so a guessed identifier reaches nothing.
04A catalogue that keeps shops consistent
Categories, brands, varieties and pack sizes live in one approved tree. A shop can propose an item and use it immediately, but it stays private until it is approved — so the catalogue grows without turning into free text.
05Sessions that can be withdrawn
Signing out ends the session everywhere it is checked, not just in the browser that asked. A valid signature alone does not grant access: pages, API routes and layouts all test the token against revocation.
What it changed
- Every millilitre is traceable to the request and the person who approved it
- Disputes are settled from the ledger instead of from memory
- Shops onboard themselves, and customers enroll per shop without a second account
- Owners run multiple shops from one login with a shop switcher
Want something built to this standard?
Tell us what you are trying to do. We will tell you honestly whether we are the right people for it.
Start a project