Inventory Management System
The problem
Jiyana is a fashion brand my partner and I founded. Every piece is made to order through tailors, and as volume grew, keeping stock records accurate took steadily more manual work.
Every stock movement was logged by hand, and checking quantity on hand meant counting physically and comparing against the records. It worked, but every manual entry carries a chance of error, and those errors accumulate. Over time the discrepancy between recorded stock and actual stock widens, and the effort to reconcile it grows with the range.
We also needed more than quantity. Because everything is made to order through tailors, items arrive in different conditions, and the commercial decision is different for each one. So the system had to capture the actual condition of every item received: what passed QC, what had minor defects but was still sellable, and what had to be rejected.
Two constraints: no software budget, and no technical staff. Whatever I built had to be operable by people whose job is running a fashion business, not a system.
What I built
Three connected layers, plus an automation layer on top.
Master product records. Every item gets a structured code carrying category, material, and colour. Alongside it: production cost per unit, the tailor responsible, and a minimum stock threshold per item.
Daily transactions. Every stock movement gets logged with date, product, quantity, and type. The important design choice here was making condition a first-class field rather than a note: received, minor defect, or reject. Product details fill in automatically once the item is selected, which removes the most common source of error, someone typing the wrong code.
Automatic summary. Enter a product code and everything else calculates: units received, how many passed QC, how many carried defects, how many were rejected and the value lost, units sold, quantity on hand, total stock value, and whether the item has dropped below its reorder threshold.
Logging through Slack. Instead of opening the spreadsheet to enter each movement, the team sends a message in Slack describing what moved, in ordinary language, and it gets recorded into the system automatically. The spreadsheet stays there for checking details and reviewing the full picture. What changed is the logging step itself, which is the part that happens many times a day.
How it runs. The automation is built in n8n, connected to Google Sheets through its API, with a language model reading the Slack message and mapping it to the right product and transaction type. That means the person logging does not need to remember a command format or an exact product code. They describe the movement in their own words, and the system handles the structure.