Building an Inventory System for F&B

Why Generic Systems Don't Work for Restaurants

I tried every inventory solution I could find. They all had the same problem: they were built for retail or warehousing, not for restaurants.

In a restaurant, the kitchen uses flour, cheese, and meat. The bar uses bottles, garnishes, and syrups. They track things differently, order at different frequencies, and have completely different workflows. Cramming both into one flat inventory list is a recipe for confusion.

Then there's the multi-location problem. I have 2 shops and 2 warehouses. Stock moves between them constantly. I need to see what's at each location in real-time, not in yesterday's spreadsheet.

So I Built My Own

The system I built handles the reality of how restaurants actually work:

Dual inventory tracking. Kitchen items and bar (hall) items live in separate systems. Each has its own categories, counting workflows, and order processes. This mirrors how real restaurant teams operate — kitchen crew manages kitchen stock, bar staff manages bar stock.

Per-outlet stock levels. Every item is tracked per location with a unique constraint: one stock record per item per outlet. When I tap on mozzarella, I see exactly how much is at Millerz Shop, SS2 Shop, Millerz Warehouse, and SS2 Warehouse. One glance, four locations.

PIN-based login. No email/password nonsense. Staff punch in a numeric PIN, the system verifies it with bcrypt, and they're in with a JWT token. Kitchen crew to managers — everyone uses the same simple flow. Different roles see different things based on role-based access control.

Built-in procurement. When stock runs low, managers create purchase orders directly in the app. Orders go through an approval workflow — request → approve → order → receive. Every step is tracked with timestamps and who did what.

The Tech Stack

• Frontend: React (Vite) + Tailwind CSS, deployed as a PWA so staff can 'Add to Home Screen'
• Backend: Node.js + Express with Knex.js query builder
• Database: PostgreSQL in production, SQLite for development
• Auth: PIN → bcrypt → JWT with role-based middleware
• Deploy: Vercel (Singapore region for low latency)

What I Learned Building It

Start with the workflow, not the data model. I watched my staff for weeks before writing any code. How do they count stock? When do they order? What questions do they ask managers? The system mirrors their actual workflow, not an imagined one.

Mobile-first is non-negotiable. Restaurant staff don't sit at computers. Everything had to work perfectly on a phone screen. Stepper buttons for counting (no typing numbers), big tap targets, fast load times.

Integers only. We tried decimal stock counts early on. It caused confusion everywhere — "Is 2.5 two and a half bags or two bags plus some?" Switching to integer-only counts eliminated a whole category of errors.

Role-based access matters more than you think. Kitchen staff shouldn't see bar stock. Staff shouldn't see financial data. Managers need different views from the boss. Getting permissions right made the app feel personal to each user.

The Results

• 20+ staff use it daily across all outlets
• Zero paper — fully digital from day one
• Real-time visibility across 4 locations
• Automated procurement with approval workflows
• Faster decisions — management by numbers, not gut feeling

For Other Restaurant Owners

You don't need to build your own system. But you do need a system that understands restaurants. If you're still running on WhatsApp and spreadsheets, you're leaving money on the table — in over-ordering, in lost stock, and in management time wasted on data entry.

The ROI isn't just in cost savings. It's in the mental bandwidth you get back when you're not constantly chasing information.

Read the full story in my [case studies](/case-studies) or [reach out](/connect) if you want to talk about building something similar.