Skip to content

Business problem & ROI ​

The concrete problem ​

Working big promotions as a brand hostess, the operational pain was always the same: information arriving too late. A busy stand might run out of drinks or merch mid-afternoon, but central coordinators only hear about it hours later — through WhatsApp or manual head counts. There is no single live picture of which zones are draining stock fastest.

That leads to visible stock-outs (empty counters, frustrated guests) and mismatched inventory — one stand holding excess while another runs dry, with no way to rebalance mid-event.

How the product addresses it ​

A coordinator opens a tablet. On a simplified venue heat map, a zone flashes a warning with something like:

High consumption: this stand may run empty in roughly X minutes (estimate).

That estimate is the Minutes to empty heuristic on Zone stock (recent pace, not ML). When another zone has spare stock, a single Suggested move nudges redistribution before guests see an empty counter. At the end of the shift, Session tally freezes Taken out / Put back / Net per zone (plus share of session out and live stock %) into a Copy handoff — the shared number that used to live only in chat threads.

What I built (frontend scope) ​

A Next.js app fed by consecutive events (mocked locally or streamed via WebSocket), with state that handles rapid updates without crashing — Zustand and a FIFO buffer capped at 10,000 events.

Two screens:

RouteRole
/Digital Command Center — SVG venue map, zone stock, Session tally (freezeable)
/dashboardLive dashboard — Leaflet map, filters, scrolling stock events

For ops teams that's faster awareness per zone and one dashboard instead of scattered messages. As an engineering demo it shows capped buffers, derived state, and dual-surface maps running entirely in the browser.

Next: Architecture · Data pipeline