# Inventory and warehouse management built around the floor > Clixo built a scanner-first inventory and warehouse system — location-aware, tied to one shared count — so receiving, picking, and shipping stop keeping separate tallies. - **Client:** Warehouse operator (NDA) - **Industry:** Warehousing - **Services:** Custom software - **Stack:** Next.js, Node.js, PostgreSQL, Barcode scanning - **Published:** 2025-09-30 - **Canonical URL:** https://clixo.sh/work/inventory-warehouse-management-system **Summary:** A scanner-first warehouse management system that replaced competing tallies with one live inventory count — from the dock to the outbound door. ## Results - **Receiving:** Scan the PO, post to a bin - **Picking:** Guided route, scan to decrement - **Count:** Cycle counts, not an annual shutdown Three teams shared the same warehouse and kept three different counts. Receiving logged what came in on a spreadsheet. Pickers pulled from a separate system that updated once a day. Shipping marked orders complete in a third tool that did not talk to either. By the time a discrepancy showed up, it had already caused a problem — a missed shipment, a phantom stockout, or an emergency order for goods that were sitting on a shelf two aisles over. The client had outgrown their patchwork. Volume was up, the catalog had grown, and the annual inventory blitz — a full weekend of counting that shut down operations — was no longer a viable substitute for knowing what was actually in the building. ## The problem The core problem was not a missing feature in any one tool. It was that no single number was authoritative. When receiving, picking, and shipping each maintained their own tally, every handoff between them became a source of drift. Over days and weeks that drift compounded until counts were meaningless. Three constraints shaped the build: - **Speed on the floor is non-negotiable.** Warehouse staff are on their feet, moving fast. Any UI that takes a long sequence of taps to complete a transaction will be bypassed. Adoption had to come from the system being faster than the workarounds, not from policy enforcement. - **No big-bang cutover.** The warehouse operates most days of the week. A hard cutover that required freezing inventory for a full recount was not acceptable. The new system had to come up alongside existing processes and earn its numbers incrementally. - **Reorder logic had to be automatic.** The purchasing team was spending hours each week manually checking which SKUs were running low. That work needed to disappear into the system. ## What we built A custom warehouse management system with a scanner-first interface, live inventory, and location tracking at the bin level. The system is the single source of truth from the moment a pallet arrives at the dock to the moment a shipment leaves. ```mermaid flowchart LR A[Receive] --> B[Putaway] B --> C[Pick] C --> D[Pack] D --> E[Ship] A -- "updates" --> INV[(Inventory count)] B -- "updates" --> INV C -- "updates" --> INV D -- "updates" --> INV E -- "updates" --> INV ``` Key modules and capabilities: - **Barcode receiving** — scan a purchase order, scan each item, confirm quantities. Stock is updated immediately and posted to the correct bin location. Discrepancies from the PO surface on the dock, not at month-end. - **Pick lists with guided routing** — pickers receive optimized routes through the warehouse. Scanning the item confirms the pick and decrements inventory in the same moment. Partial picks and exceptions are handled in-flow, not on paper after the fact. - **Bin-level location tracking** — every SKU has a home and a history. Putaway and replenishment workflows keep the map current. Locating a product takes a search, not a walk. - **Cycle counts** — instead of a single annual shutdown, small count tasks are generated continuously and assigned to staff during low-traffic windows. Discrepancies are resolved while memory is fresh and impact is small. - **Automatic reorder points** — configurable per SKU based on lead time and average daily movement. When stock drops below the threshold, a purchase suggestion is generated. The purchasing team reviews, not hunts. The architectural decision that made everything else possible was treating the scan event as the transaction of record, not a secondary confirmation. Every receiving scan, every pick scan, every count scan writes directly to the inventory ledger with a timestamp and a user. There is no batch job reconciling systems overnight. The count is current because the count is what the scans say it is. ## How we approached it The first stretch was discovery and scaffolding: walking the floor with receiving staff, pickers, and shift supervisors; mapping every handoff where a count changed hands; and building the data model around those real workflows rather than around a generic WMS template. Receiving and bin assignment came next — the top of the inventory funnel. Getting that right first meant the system was building an accurate count from day one of parallel operation. Staff ran both the old spreadsheet and the new scanner workflow during this phase. When the numbers matched, confidence grew. Pick workflows and shipping confirmation followed. This was the highest-stakes phase for adoption because any slowdown on the pick floor has immediate downstream consequences. We ran structured shadowing sessions — a developer alongside a picker for a full shift — and iterated the UI before committing to the rollout. The acceptance criterion was simple: a trained picker should complete a scan without breaking stride. Cycle counts, reorder automation, and the formal cutover came last. Because the system had been building its own count in parallel, the cutover was a declaration, not a migration. Staff signed off on the delta, we archived the old spreadsheets, and the scanner became the only authoritative input. ## What we will not claim No inventory-accuracy percentage, no pick-time cut, no stockout reduction. Those figures are not in this repo. The public claim is the system: one scan-backed count, bin locations, guided picks, and reorder suggestions that replace the weekly hunt. [Start a build](https://clixo.sh/#contact) or learn more about our [custom software development](https://clixo.sh/services/custom-software-development) practice. --- Clixo · 1141 W Bryn Mawr Ave, Itasca, IL 60143, US · [hello@clixo.sh](mailto:hello@clixo.sh) [Start a build](https://clixo.sh/#contact) · [All services](https://clixo.sh/services) · [Agent guide (llms.txt)](https://clixo.sh/llms.txt)