Built overnight against a two-day deadline. Here's what it's grown into since.

A deadline accounting didn't set

A client needed a full physical inventory count of their warehouse stock, not a lighter audit or a sample check: the prior count hadn't been done correctly, and the gaps it left behind were already causing problems downstream. The only way to trust the numbers again was to record every item, one by one, not spot-check a sample and assume the rest held up, and then reconcile against the ERP. The ERP side came to us as a spreadsheet export of more than 180,000 SKUs to search and match against. On paper that's an accounting job. The deadline, though, wasn't set by accounting.

Installers couldn't roll their trucks out to the day's install jobs until the on-truck inventory was verified, and receiving of new stock couldn't happen while the count was ongoing, either, since inventory moving mid-count would have corrupted the very numbers being reconciled. So the active count had to close in a single day, with only dead inventory allowed to roll into a second, or interrupt revenue-generating operations and make customers unhappy.

The slow part was the lookup. Confirming that what was actually on the shelf matched a specific SKU in the records meant searching a 180,000-row spreadsheet by hand, and that was taking anywhere from 45 to 90 seconds per item. Some items on the shelf weren't in the catalog under their own identity at all, having originally been received into a generic, catch-all SKU instead of one specific to the item. We knew that going in. Matching physical stock against the catalog is the only thing that makes a gap like that visible, which is part of why the count was worth doing at all.

An overnight build that paid for itself by lunch

The tooling to verify on-truck inventory before installers could roll out didn't exist yet, so day one ran by hand: the only way to find out where the friction actually sat and how the people on the floor actually worked. The count went a full day, from 5:00 AM to roughly 5:30 PM, and closed everything except dead inventory, the most scattered and least-tracked stock. What rolled into day two was that dead inventory, plus anything hidden or miscounted the first time through.

Rather than keep counting by hand against a static sheet, we built a first-pass lookup tool overnight:

• A simple list of the full catalog to search against
• Direct and fuzzy search, so a near-miss on spelling or SKU format still found the right item
• A local or lightweight server-run mode, so more than one person could use it at once

Per-item lookup time dropped from 45-90 seconds by hand to roughly 5 seconds, a difference that compounds across every item counted. It paid for itself before lunch on day two, working through the dead inventory faster than we otherwise could.

Becoming Inventory Count Helper

Once the count itself was through and notes could be organized and digested, the first-pass tool got generalized and improved into Inventory Count Helper, an internal W&W tool built to handle any catalog, not just the one it started on, with client-specific integrations layered on as each engagement needs them:

• CSV/Excel catalog import with an explicit column-mapping step, so it adapts to whatever export format a client's own inventory system produces
• Barcode scan as the highest-priority exact-match tier, checked before any text search, because a scanned barcode is the one input that's never ambiguous
• Fuzzy, natural-language fragment matching with a numeric confidence score and an explainable basis, showing which query terms matched and which were ignored, not a black-box similarity score
• A per-field audit log on every count entry: old value, new value, actor, device, and timestamp
• Offline-safe multi-device sync, since warehouses routinely have spotty cell service and no reliable building internet away from the front office; each count entry carries a device ID and a client-generated event ID, so a phone that drops signal mid-count and resyncs later can't double-log a count
• A live device-presence indicator showing how many devices are actively counting at once
• A fully offline, packaged desktop build requiring no internet connection
• An extension system to allow for special processing of entered information, such as pulling data from QR codes or URLs or special handling when a barcode or input matches a pattern
• An optional relay fallback to another running instance for use with slow connections to process more complicated input (URLs from QR codes, structured data, etc.)

What's grown since

The tool didn't stop at the first generalization. Several of the capabilities above have grown since, and a few new ones joined them:

• The extension system started as a placeholder for "pull data from QR codes or URLs." It's real now: scanning a garage door panel's QR code pulls that item's actual specs from the manufacturer's own product lookup, not just a SKU match against the client's spreadsheet, with the extractor architecture built to add more manufacturers without touching the core matching engine. Extracted data stays in its own table, never mixed into a client's own catalog
• New: taking a picture of a label or tag runs it through that same extraction pipeline. A review window shows what was detected before anything is saved, and from there it either creates a brand-new catalog item at zero count or, if the barcode matches something already on file, links the photo to that existing item and fleshes out its information instead of creating a duplicate
• The relay fallback generalized into a configurable list of remote servers, each usable as a relay and/or a storage target, with a sync queue and offline handling, so a slow-connection site isn't limited to a single fallback instance
• New: photo processing and QR/URL lookups now share one processing queue on both mobile and desktop, with visible status, retry, and cancel, so a person on the floor can see what's still working through instead of wondering if a submission went anywhere

The mobile scan workflow got hardened by real use, not just testing at a desk: a handheld scanner delivering barcodes into a phone's text field kept popping the on-screen keyboard open, so the scan field now knows the difference between being scanned and being typed into, a fix that's invisible in a demo but real on a shift. And signed, cross-platform desktop builds now come out of the same pipeline that tests the tool, so Inventory Count Helper can run directly on any local machine instead of needing a special device brought to every count.

Now with Inventory Count Helper able to work with any catalog providing at least an ID or barcode and a description, the same tool and approach will carry forward to every count after this one and is ready for further improvement with each engagement. It now has a public demo, deployed on its own with fixture data that auto-refreshes, and some features disabled. All built from a new infrastructure setup and deployment method we've automated.

Here's what the current build looks like, on synthetic demo data.

←→

×←

→