Restaurants managed inventory through a combination of experience, memory, and spreadsheets.

Inventory counts happened once a month - someone would walk through storage areas with pen and paper, writing down quantities of ingredients across multiple locations and then re-type everything into a spreadsheet.

Purchasing decisions based on intuition rather than data contributed to over-ordering and food waste.

The bottleneck wasn't the count itself. It was everything after.

Before any financial reporting could happen, staff had to manually match those inventory numbers against supplier invoices to get up-to-date cost data - only then could the kitchen calculate COGS and generate accounting reports. In hospitality, COGS is one of the primary levers for profitability. Wasted stock and slow reconciliation both hit the same number.

Each manual step introduced delays, errors, and dependency on whoever held the institutional knowledge.

The product focused on eliminating the reconciliation work surrounding the stock count: building a shared operational layer where kitchen staff, managers, and accountants worked from the same data without manual handoffs.

The platform supported four distinct roles:

• kitchen staff performing counts
  
• staff managing order receipts and costs
• managers monitoring inventory and performance
• accountants accessing auto-generated reports.

The web platform replaced fragmented spreadsheets with a structured inventory system. One dataset supported the entire workflow.

The obvious starting point was barcode scanning. We ruled it out - most produce arrives fresh and loose without barcodes, and available ingredient databases were too incomplete to be reliable.

Staff had been using paper for counts - mobile was the natural replacement. With barcode scanning ruled out, search became the primary interaction.

Partial string matching meant typing the first few characters returned results immediately, without needing to know exact supplier naming or scroll through a full list.

The count flow moved items from uncounted to counted, giving staff a clear overview of what is still left to count.

Units were the harder problem. Staff might count a full carton, loose packages, and individual items in the same session. We supported three unit layers - base, purchase, and stocktaking - each carrying its own cost, so the system absorbed the messiness of physical storage rather than forcing mental conversion before entry. Resolving cost per unit at input prevented downstream reconciliation errors where the same ingredient appeared at conflicting values.

Counts could be filtered by category - allowing high-value or high-turnover items like meat, alcohol, or dairy to be counted independently, as often as needed.

Previously, generating inventory reports meant manually preparing spreadsheets. With the digital system, reports were created automatically once stock counts were completed.

The team collaborated with several senior product designers over the years and each handoff risked pattern drift. I developed a component and pattern library which became the continuity layer: tables, graphs, navigation, modals, dropdowns, calendars, autosuggests - complex interactive components that needed to behave consistently across web and mobile regardless of who was designing.

Tokens weren't available in Figma at the time, and when variables arrived, the conversion cost outweighed the benefit - color and text styles were mostly enough. Auto-layout was a different call. Manually repositioning elements was a daily friction point with compounding cost, so the investment paid back quickly.