CodeNine

Work / Cha & Chill · since 2020

Nobody hands over their operations on day one.

They hand over a website. Six years later we maintain the ERP a 27-branch franchise runs on, built with their people rather than delivered to them.

Client
Cha & Chill · Tanzilur Rahman
Relationship
2020 – present, continuous
Our role
Build and custody, ongoing
Stack
Django · PostgreSQL · React · React Native · Electron
Cha & Chill ERP, branch inventory, wide

The arc

2020

A static website

The whole engagement. Nothing more was asked for.

Then

Small tools, one at a time

Digital coupons. Expense management. Whatever the business needed next.

The pattern

Nothing off the shelf fit

Factory and RMG ERPs are everywhere. We could not find one built for this shape of business.

Now

The ERP the business runs on

Years of joint development with Cha & Chill’s own people.

The core of the model

What leaves the kitchen is not what the branch sells.

Nodes are surfaces. Solid edges carry goods. Dashed edges carry the reconciliation.

Kitchen to branch inventory transformationThe master kitchen produces 200 singara and transfers them as goods to a branch. At the branch, one singara plus onion plus sauce is assembled into one combo, a different SKU. The branch sells 200 combos through the point of sale. Inventory reconciliation spans both ends: 200 singara produced against 200 combos sold, because the unit of production is not the unit of sale.01 · ProducesMaster kitchen02 · AssemblesBranch ×2703 · SellsPoint of saleGoods200 singaraDifferent SKU200 comboSingaraOnionSauce++=ComboOne recipe,held by the systemProduced · 200Sold · 200Inventory reconciliationThe unit of production is not the unit of sale. Stock has to balance across the transformation,or variance is indistinguishable from theft.27 branches · every SKU mapped to its recipe · variance visible per branch

Why the problem was hard

The menu transforms between kitchen and branch.

Master kitchen sends a singara. The branch sells it as a combo with onion and sauce. What is produced and what is bought are different SKUs, and the system has to hold both.

01
Recipe-based inventory across that transformation

Tracking stock when the unit of production is not the unit of sale.

02
Expenses scattered across the operation

Master kitchen, each branch’s daily spend outside the kitchen, fixed costs, marketing. All in different places, all needing to roll up.

03
Kitchen-to-branch delivery and tracking

Across 27 branches, with dispatch and receipt reconciled at both ends.

04
A franchise that keeps growing

Nothing in the model can assume a fixed branch count.

05
Anti-corruption controls throughout

Anyone who has run multi-branch food service knows shrinkage is the problem. Operational systems built for the reality that some inputs are dishonest.

Three surfaces

Branch operations need desktop, mobile and web.

Electron on the terminal, React Native in hand, React in the back office. One data model behind all three.

Electron POS terminal, 4:3

Electron

Branch terminal

Integrated with BPOS for in-shop sales.

Handheld order terminal, 4:3

React Native

Kitchen dispatch

Production, dispatch and branch receipt, on the floor.

Cha & Chill ERP back office, 4:3

React

Back office

Recipe costing, expense rollup, branch comparison.

Stated plainly

Who owns what, and where the ERP could go next.

The ERP
CodeNine’s product and IP.
BPOS
The POS it integrates with. BizSolution’s product and IP. Sister concerns under common ownership, stated rather than left to surface later.
The category
Central kitchen with branch-level assembly is not an unusual model. It just was not served by anything we could find.
Generalises to
Other multi-branch F&B operations built the same way.

Next case study

Vapex

Every operational surface of one business, including partner-wise profit allocation.

Entry offer

Inherited Codebase Review

2–3 days, read-only repo access.