Loading...
← All work
Case study · MehmaanDelivered
A point of sale that follows the rules of a real dining room.
A point-of-sale system for dine-in, takeaway and delivery. Waiters take orders on a tablet, the kitchen gets a ticket, managers approve voids, and the bill applies the right tax for cash, card or bank transfer.
- Sector
- Restaurants & Hospitality
- Our role
- Domain modelling, API architecture, web application, automated testing
- Capabilities
- Platforms · Mobile
- Status
- Delivered
The challenge
Generic tills break on local rules.
Restaurant software built elsewhere rarely fits local rules: tax differs by payment method, service charges vary by table, and voided items need a paper trail. Mehmaan was built around those rules instead of bending them into a generic till.
What made it hard
- 01
Conditional tax logic
Tax depends on the payment method and service charge on the table, so totals cannot be a single formula.
- 02
State drift
If kitchen tickets reference live orders, later edits silently rewrite what the kitchen already cooked.
- 03
Accountability
Every void needs authorisation and an immutable record of who, when and why.
The approach
Model the domain first, then let the software follow the rules.
We modelled tables, sale types, kitchen tickets, voids and tax as first-class entities. Kitchen tickets are immutable snapshots, tax rates are configuration rather than code, and role-based access with JWT auth and rate limiting protects every money path, each covered by automated tests.
System map
- AI step
- Person in the loop
- Service or store
How it works
- 01
Order
A waiter picks the table and sale type, then taps items from a categorised menu.
- 02
Fire
A kitchen order ticket is snapshotted and sent, so later edits never rewrite what the kitchen saw.
- 03
Correct
Voids need a manager, and every void is stored with who, when and why.
- 04
Settle
Service charge and tax are calculated for the chosen payment method, then the bill prints.
- 05
Learn
Daily sales, open tables and guest reviews roll up for the owner.
Key decisions
Decisions that keep the numbers right.
Decision 01
Snapshots, not references
Kitchen tickets copy the order at send time, so the kitchen and the bill can never disagree silently.
Decision 02
Tax as configuration
Rates for cash, card and bank live in data, so a budget change is a setting, not a release.
Decision 03
Tests on the money paths
Order, void and auth controllers are covered by automated tests before anything ships.
What shipped
A POS for dine-in, takeaway and delivery.
Order flow
Table and sale-type aware ordering from a categorised menu.
Snapshotted kitchen tickets
Copied at send time, so kitchen and bill can never disagree silently.
Authorised voids
Manager approval, with an audit record for every void.
Payment-aware billing
Service charge and tax resolved per payment method from configuration.
Owner reporting
Daily sales, open tables and guest reviews aggregated for the owner.
Architecture
A cross-section of the system.
Every layer, from what people touch down to where it runs, and the one job each layer does.
L1Services
Node.js+Express
REST API for orders, tickets, voids and billing.
L2Security
JWT auth+Rate limiting
Role-based access for waiters and managers, and throttling on every endpoint.
L3Data
MongoDB
Orders, snapshotted tickets, void records and tax configuration.
L4Quality
Jest
Automated tests on the order, void and auth controllers.
L5Infrastructure
Docker
Containerised for repeatable deploys.
Our scope
Domain modelling/API design/Web application/Role-based access/Automated testing
Where it is now
Delivered, with the money paths under test.
Mehmaan is delivered. Order, void and auth paths are covered by automated tests, and tax rates live in configuration, so a budget change is a setting rather than a release.
Something like this in mind?
Tell us the problem. We will tell you honestly if we are the right team to solve it.