Picking and dispatch screens for a cold-chain distributor

Pickers were working from paper lists printed at the start of a shift, and by mid-morning the list was wrong — orders had been amended, stock had been moved, and a chilled item picked into the wrong staging lane is a write-off rather than a re-shelve. Supervisors spent their day walking the floor correcting things verbally. The business wanted the pick list to be live and to stop the two mistakes that cost real money: picking from a bin that had been re-stocked with a different batch, and staging a chilled order in an ambient lane. It also had to work for people wearing gloves, in cold, on devices bought years ago.

Contract developer on the front-of-warehouse team, about seven months, one of five developers plus a solution architect who owned the integration with the warehouse management system. I was the senior person on the handheld side and did the estimating for that slice. There was a product owner from operations and a supervisor seconded two days a week to tell us when we were wrong, which we were often. I was also on the go-live rota for the first three weeks after each site cut over.

I owned the handheld application end to end — the screens, the offline behaviour, and the sync protocol back to the order service. That meant designing for a scanner-first interaction where the barcode is the primary input and the screen mostly confirms, rather than a form you tap through. I built the batch and temperature-zone checks that block a confirm, and the exception path for when a picker legitimately needs to override, which writes a reason and a name. I did not own the warehouse management system integration itself, but I wrote the contract for it with the architect and most of the reconciliation logic when the two disagreed.

I argued hard for treating the handheld as offline-first rather than assuming the wireless network. The site surveys said coverage was fine; the freezer aisles said otherwise, and a picker standing still waiting for a spinner is the failure mode that makes people go back to paper. So every pick is queued locally and confirmed against the server when it can be, with the conflict rules written down before we built anything. The alternative — a thin client with a loading state — was simpler and I have used it elsewhere, but not here. I also pushed back on adding a photo-capture step the client wanted, on the grounds that gloves plus a five-year-old camera equals a queue at the staging door.

The devices were fixed: an existing fleet of rugged handhelds with small screens and a browser several versions behind, so no modern layout features and a lot of manual testing on the real hardware. The warehouse runs 24 hours, so releases went out in a Sunday window between shift patterns, one site at a time, with the previous version kept installable. There was a peak freeze from October through the holidays. And the warehouse management system was a vendor product we could not change, whose API returned success for one class of failure, which we found in week three and had to design around because the vendor's fix was six months out.

Mis-picks that reached staging dropped by around forty per cent in the first quarter across the two pilot sites, measured on the existing exception log rather than anything we built. The bigger change was that supervisors stopped relaying corrections by voice — the amendment reaches the handheld, so the walking around stopped being the mechanism. Pick times were roughly flat, which I count as fine given we added two checks. One site rolled back on the first attempt because of an unrelated network change, and the ability to reinstall the old version that same night is the reason it was a bad evening rather than a bad week.

The seconded supervisor was effectively our designer — he redrew the confirm screen twice and both times he was right. The solution architect owned the vendor relationship and did the unglamorous work of proving the API bug so it could be escalated. A QA engineer built a rig that replayed real scanner input at speed, which caught a race in the offline queue that no manual test would have.