How We Built a Real-Time Inventory Dashboard for a $2M Fulfillment Operation in 6 Weeks

## Overview In the bustling logistics corridor outside Bengaluru, a faceless-but-efficient e-commerce fulfillment center was processing roughly 2,800 orders per night. On paper, the operation looked fine — shipments went out, customers received parcels, revenue kept ticking. But beneath that calm surface, the internal operations team was living a quiet crisis every single night. The problem was twofold. First, their primary inventory system — a legacy monolithic web application built on a PHP framework several versions behind end-of-life — reconciled account records against physical stock only once every twenty-four hours. That batch window left a 24-hour shadow where no one knew with confidence what actually existed in the warehouse. Second, the reconciliation process itself was manual: four team members would pull printouts, cross-check rows in a spreadsheet against physical bin counts, and manually adjust 'phantom stock' and 'phantom gaps' in the system — a process that consumed nearly four hours every evening and was prone to human error. The result was visible in their KPIs, even if no single week saw a catastrophic failure. On-time dispatch rates hovered between 87% and 92%, well below the 98% SLA threshold they had committed to with their top-tier marketplace partners. Stockout incidents — where the system showed an item as available when the bin was empty — contributed to roughly 8–12% of their late orders. And the team was burning out: the nightly reconciliation ritual had become a stressful, thankless grind. They reached out in early March for a solution. We kicked off on March 4th and shipped a production-ready, real-time inventory management dashboard on April 15th — six weeks, one zero unplanned post-launch rollbacks, and one very relieved operations manager. ## The Challenge To understand why this problem was so persistent, it helps to zoom in on the specifics of the environment. The fulfillment center occupies 18,000 square feet and is organized into four temperature zones across three mezzanine levels. Inventory is stored on pallets, in mesh bins, and in interchangeable pick carts. SKU count was roughly 4,200 at the time of engagement, spread across three major product categories: consumer electronics, home and kitchen goods, and personal care items. The center was projected to scale to roughly 6,000 SKUs and 5,000 nightly orders within the next nine months. The legacy system's architecture was typical of operational software built in the early-to-mid 2010s: PHP 5.6 monolith, a single large MySQL database, nightly batch cron jobs for reconciliation, and an HTML view layer that had evolved through several design iterations with no consistent component system. There was no real-time data layer, no websocket or Server-Sent Events support, and no separation between the data-access and presentation layers. The daily reconciliation workflow was ingeniously primitive: each night, one staff member would run a SQL export from the MySQL database, share it via local network file share with three other team members, and everyone would open it in Excel. They would then physically visit bins flagged as discrepancies in the export, count stock on hand, and manually enter correction rows back into the system — an entirely manual feedback loop with no audit trail, no version history, and no rollback mechanism. One bad correction entry could cascade and affect weeks of reports. Beyond the operational pain, there was a business cost. The marketplace integration they depended on penalized late dispatches at a tier that added up to roughly ₹1.2 lakh — about $1,400 USD — per month in SLA breach penalties. Inventory inaccuracies caused over-ordering of slow-moving SKUs and under-ordering of fast-movers, adding estimated carrying costs of ₹4–6 lakh additional working capital tied up in misplaced stock. ## Goals We worked with the operations leadership to define three concrete, measurable goals before we wrote a single line of production code: 1. **Reduce nightly reconciliation time to under 30 minutes** — The benchmark was the four-hour manual process they were living with. We targeted 30 minutes of active human involvement, with most of the heavy lifting moved into the system. 2. **Achieve **on-time dispatch rate of 98% or higher** — This was tied directly to their SLA commitments with marketplace partners and would eliminate the recurring monthly penalties. 3. **Reduce phantom orders and phantom stock events by 90%** — By making inventory data visible and actionable in real time, the number of orders placed on non-existent stock should drop dramatically. These goals were framed as post-go-live North Star metrics — we did not consider the project successful unless all three were met within the first 30 days of full production rollout. ## Our Approach ### Discovery and Architecture (Weeks 1–2) We started with a two-week discovery phase rather than jumping straight into implementation. We spent time on the warehouse floor, observed the nightly reconciliation process from start to finish, and mapped every touchpoint where data was entered, exported, corrected, or reentered. Three critical architectural decisions emerged from that process: **First, we needed to decouple the data layer from the legacy system.** Rather than trying to patch or refactor the PHP monolith in place — a high-risk path given its critical production role — we designed a read-optimized operational data store. This store received a real-time notifications feed from the order management system (via webhook) and applied the existing nightly reconciling logic as a continuous background service. This gave us near real-time inventory state without breaking any existing contract with the legacy system. **Second, we built the data pipelines as event streams, not batch jobs.** Every inventory event — a stock-in, a dispatch, a manual adjustment, a return receipt — produces an immutable event record. This gave us not only the current state but a durable, queryable history that the operations team could use to understand patterns without calling engineering every other day. **Third, we targeted a specific, contract-driven API contract.** The operations team had suffered from spreadsheets with inconsistent column names ad-hoc calculations. We specified every dashboard element as a named, typed API field with an associated data contract and performance SLO. The tech stack we selected was intentionally pragmatic: Node.js with TypeScript for the API and pipeline services, PostgreSQL for the operational store, Redis for caching the most frequently updated inventory counters, and a Next.js frontend with Tailwind CSS for the dashboard. The choice of Next.js gave us server-side rendering for fast initial load times, while React Query provided the real-time state management that the operations team needed to perform live filtering and sorting without full page reloads. ### Implementation Phase (Weeks 3–5) Week three was about data ingestion. We built three pipeline components: an order events consumer (picking up webhook events from the order management system), a barcode scan consumer (ingesting scan events from the warehouse handheld scanner fleet), and a reconciliation corrections ingest point (allowing the operations team to make corrections through the new system rather than Excel). Week four was the dashboard build. The core dashboard displays four major panels: (1) a live inventory heat map grouped by zone and pick-cart status, (2) a 24-hour dispatch trend chart, (3) a discrepancy summary table showing SKUs that have drifted outside agreed accuracy thresholds, and (4) an actions panel surfacing the top three priority corrections for the shift. We added three specific features the operations team identified during the discovery process: (a) a one-click 'run reconciliation' button that re-evaluates a selected SKU or zone in real time (rather than waiting for the daily batch), (b) a persistent audit trail showing every correction made — who, when, and what the before/after values were — satisfying their compliance requirements, and (c) a Slack notification rule that surfaced discrepancy alerts to the operations lead rather than burying them in an admin report. Week five was integration and load testing. We stood up a full staging environment, seeded it with three months of synthetic warehouse data, and ran six simulated order-volume spikes to validate that real-time updates did not lag and that the reconciliation pipeline could handle their projected 5,000 order/day load at peak period. The staging environment caught one important issue: under peak simulated load, Redis cache keys were expiring before being refreshed, causing a brief 3–5 second UI lag on the inventory heat map. We fixed this by introducing a background key refresher that ran every 30 seconds on monitored cache entries — a small change, but it preserved the illusion of real-time speed that the dashboard's credibility depended on. ### Launch and Rollout (Week 6) The launch strategy was deliberately low-risk. We ran the new system side-by-side with the legacy system for the first ten days in full parallel. During that period, the operations team continued to run their nightly reconciliation alongside the auto-reconciliation every night. Each morning, we collected discrepancy reports from both systems side by side and corrected any logic errors before they could compound. The rollover point was clean: the final parallel night showed zero reconciliation discrepancy between our system and the manual spreadsheet. The operations manager signed off the following morning, and we sunset the nightly four-hour Excel ritual entirely. ## Results The numbers tell a clear story, but the on-the-ground change was perhaps more meaningful. Four hours every night reduced to twelve minutes of active human involvement on the new system. The remaining ten minutes were spent reviewing flagged high-value SKU discrepancies and signing off on corrections — a fundamentally different quality of work for the operations team. 📊 **Key metrics at 30 days post-launch:** | Metric | Before | After | Change | |---|---|---|---| | Nightly reconciliation time | 4hrs (240min) | 12 min | -95% | | On-time dispatch rate | 87–92% | 98.4% | +6.4–11.4 pp | | Phantom stock incidents / week | 8–12 | 1.1 | -90% | | SLA penalty costs / month | ₹1.2L (~$1,400) | ₹0 | -100% | | Inventory accuracy | ~83% | 99.1% | +16.1 pp | | Working capital freed up | — | ₹5.2L (~$6,100) | CFO win | The on-time dispatch rate exceeded the 98% target in the first full production week. Phantom stock incidents averaged 1.1 per week — a 90%+ reduction against the baseline of 8–12 per week during the legacy system period. The first month also saw a complete elimination of monthly SLA penalty charges — a saving of roughly ₹1.2 lakh per month, or approximately ₹14.4 lakh annually. From a team morale perspective, the operations team reported a significant reduction in end-of-shift stress and a notable shift in how they talked about their work — less as managing a nightly emergency and more as monitoring a dashboard and catching exceptions early. The CFO, reviewing the working capital metrics, noted that the improved inventory accuracy had freed up approximately ₹5.2 lakh in working capital that had been sitting unnecessarily in overstock of slow-moving SKUs — a benefit that had not been part of the original project scope. ## Lessons Learned This project surfaced several lessons that we are now carrying into other operational technology engagements. **1. Map the human workflow before the code — and respect what you find.** The four-hour reconciliation ritual was not an accident; it existed because every failed attempt to solve it technically had left the team with no better alternative. By spending two weeks on the floor, we found the actual toil — which was predominantly low-level data matching in Excel — rather than building a solution for a caricature of the problem. The operations team became our best designers. **2. Don't rewrite the monolith — build around it.** The legacy PHP system was locked in production due to compliance requirements that made refactoring high-risk. Rather than fighting that constraint, we accepted it and designed the architecture around it. A read-optimized event stream sits beside the legacy system and feeds it write corrections. Both systems work in concert; neither is replaced. **3. Near real-time is a psychological threshold, not just a technical one.** The root cause of phantom stock was not 'slow data' as much as 'wrong expectations of data freshness.' Warehouse staff were making decisions based on a 24-hour-old picture and calling it 'current.' Making current views genuinely real-time — or within ten seconds of an actual event — reset their expectations and changed behavior without any process training required. **4. Instrument your own rollout.** Running in parallel for ten days was an investment that paid off immediately. By the time we handed over full production, every team member knew exactly how to operate the new system, every discrepancy scenario had been fixture-tested, and the first post-launch week ran without incident. The side-by-side period is non-negotiable when the legacy system is in production serving real revenue. **5. Accuracy improvements unlock working capital — that's a CFO argument.** Many operational technology projects are sold and scoped through the lens of efficiency or cost reduction. Working capital is a different and often larger axis of value. Demonstrate that faster, more accurate inventory information directly reduces the capital tied up in stock — and you'll have a completely different conversation at the table. Looking ahead, the fulfillment center is already in discussion with us about adding predictive capacity planning and automated reorder recommendations on top of the current dashboard layer. The real-time foundation makes those features straightforward. The harder part — building trust in the data — is already done. --- *This case study was produced by the WebSkyne editorial team in collaboration with our engineering, product, and delivery practices. For questions about how a similar engagement could apply to your operation, reach out to editorial@webskyne.com.*