A desktop app that talks straight to the scanner
A cross-platform desktop app that reads barcode scanners and label printers directly, processes inventory counts locally, and keeps running through the warehouse's dead cell coverage.
How the work was scoped
Warehousing & Fulfillment
11 weeks
Fixed price
Client name withheld under NDA. Engagement details are shown to the extent our agreement permits.
Direct hardware access
Talks to scanners and label printers over USB and serial, which a browser can't do.
Barcode scanners and label printers speak over USB HID and serial, which a browser can't reach. Electron with node-serialport talks to them directly, so a scan lands in the app with no keyboard-wedge workaround, and a label prints to the right printer on the right stock with no print dialog. Device configuration is per terminal, so each station knows its own hardware.
- Direct USB HID and serial access, with no keyboard-wedge hack
- Labels print to the right printer and stock without a dialog
- Per-terminal device configuration
What this terminal is talking to: a handheld scanner on serial, a ring scanner on USB HID and the label printer on its own port, the pallet arch unplugged six days ago, and the bytes each port has carried in the last hour.
The server cannot be reached: forty-seven put-aways held on the terminal itself, each written to disk as it was scanned, the scanners and bay rules still working, and an earlier link that dropped halfway keeping the fifteen movements it had confirmed.
Local-first counts
Inventory processing runs on the terminal and reconciles when a connection returns.
Counts write to a local SQLite database first and reconcile with the server when a connection returns, so a warehouse dead spot doesn't stop a stock take. Reconciliation runs per movement, which means a partial sync makes real progress instead of failing whole and starting over. The operator sees pending counts explicitly, so nobody has to assume everything landed.
- SQLite-first writes; a dead spot doesn't stop a count
- Reconciled per movement, so partial syncs make progress
- Pending counts shown explicitly, never assumed sent
Managed updates
Eighteen terminals, one build: a canary terminal first, then the Windows and macOS terminals on the floor over two days, installed on restart with nothing rolled back, and a pin that holds the site on this build through a peak week.
A signed auto-update channel keeps every terminal current without a manual reinstall.
Installers are code-signed on Windows and notarized on macOS, because an unsigned build is one an IT team won't deploy and an operator will click past. Updates roll out on a staged channel (a canary terminal first, then the floor) and can be pinned per site, so a peak week isn't interrupted by a release nobody asked for.
- Signed on Windows, notarized on macOS
- Staged rollout: canary terminal before the floor
- Version pinning per site through peak weeks
What we were brought in to do
Inventory counts ran through a browser tab that couldn't see the barcode scanners or label printers on the floor, so staff retyped codes by hand and counts drifted from what was actually on the shelves.
A distribution facility running inventory counts through a browser tab on terminals bolted to the racking. The scanners and label printers on those terminals connect over USB and serial, so the browser could see neither. Staff were scanning into a handheld, reading the number aloud, and typing it in. The engagement started after a quarterly count that took three days and still disagreed with the shelves.
Desktop Engineering
Where the old way broke
The warehouse's scanners and printers connect over USB and serial, which a browser sandbox can't reach, and the facility's cell coverage is unreliable enough that a web app dropped mid-count regularly.
Two failures compounded. Transcription introduced errors at a rate that made the count itself untrustworthy, and the facility's cell coverage dropped often enough that the browser tab lost its session mid-count and discarded the entries. Staff had learned to count in short bursts and save constantly, which is slower and still lost work.
We built a cross-platform desktop app with direct hardware access to the scanners and printers, local processing so counts don't depend on a live connection, and a code-signed auto-update channel so every terminal stays current without a manual reinstall.
What we built together
- 01
Scoped the hardware integration against the warehouse's actual scanner and printer models
Two of the facility's printers turned out to need vendor-specific escape sequences, which no generic driver assumption would ever have produced.
- 02
Built local-first inventory processing that reconciles once a connection is available
Counts write to a local database first and reconcile per movement when a connection returns, so a partial sync makes progress instead of failing whole.
- 03
Wired direct USB/serial access to scanners and label printers
Two of the facility's printers needed vendor-specific escape sequences, the kind of thing you only find by testing against the actual hardware.
- 04
Set up code signing, notarization, and an auto-update channel across all terminals
Signed and notarized builds roll out on a staged channel (a canary terminal before the floor), with version pinning available per site through peak weeks.
Phase by phase
Phase 1: Scope hardware
The models actually on the floor
Scoped the integration against the warehouse's real scanner and printer models, with no generic driver assumptions.
- Hardware inventory
- Integration spec
Phase 2: Local-first
Counting without a connection
Built inventory processing that completes locally and reconciles once connectivity is available.
- Local store
- Reconciliation logic
Phase 3: Wire devices
USB and serial
Implemented direct device access for scanners and label printers, with per-model quirks handled explicitly.
- Device layer
- Printer templates
Phase 4: Distribute
Signed and self-updating
Set up code signing, notarization, and an auto-update channel across every terminal.
- Signed installers
- Update channel
- Rollout plan
A cycle count in aisle C: nine bays counted against what the system expected, four of them off by nine cases in total, each with the reason it drifted, and every bay and case scanned, none keyed.
Operational results after launch
+31%
Count accuracy
0
Re-typed codes
100%
Terminals on latest build
Count accuracy is measured against a controlled recount of the same aisles, before and after, never against the system's own figures. Retyped codes is literal: there's no keyboard path for a code anymore. Terminals on latest build is measured from the update channel's own check-in telemetry.
Client name withheld under NDA. Figures are approximate, drawn from the engagement’s own reporting.
About our collaboration
A cross-functional team of 5 worked on a fixed price basis over 11 weeks, covering Desktop app build, Hardware integration, Signed installer & auto-update. We shipped in two-week increments, each one releasable and reviewed with them before it merged. Decisions were written down as they were made, so the reasoning outlived the people who made it.
Hardware was scoped against the facility's actual scanner and printer models in week one, with no generic driver assumptions, and that's the step that decides whether this kind of integration works at all. Builds went onto two real terminals from week four, and the update channel was tested by shipping deliberately trivial releases before anything important depended on it.
What we'd carry into the next one
- 01
The dead cell coverage was the requirement, not an edge case. Local-first was the only workable shape.
Poor coverage wasn't an edge case to handle. It was the operating condition, and a design that treats the network as optional is a different design from the ground up, not a hardened version of the old one.
- 02
Generic driver assumptions fail on real hardware; scoping to the actual models saved the integration.
The models mattered: two of the facility's printers needed vendor-specific escape sequences that no generic driver assumption would have produced.
- 03
With dozens of terminals to keep current, code signing and notarization belong in the plan from day one.
With dozens of terminals, an unsigned build is one IT won't deploy and an operator will click past. Signing is what makes the update channel usable at all.
One pallet, four steps
From the bytes on the port to the bay, a code never passes through a keyboard.
Pallet 8841 as the terminal sees it: the frame read off the serial port, the label fields parsed out of it, the checks against its order line, and the bay scan that accepts or refuses it. Switch tabs, or use the arrow keys once one is focused.
The handheld scanner reads the pallet label and writes the frame to serial port COM4. The app reads the port itself, so there's no text field that has to have focus and no keystrokes standing in for a barcode.
]C1 names the symbology, GS closes the variable batch field, CR ends the frame. Frame complete.
- Serial read
- 2Label parsed
- 3Checked against the order
- 4Accepted or refused
Reveal timings are illustrative. The values follow pallet 8841 through the same data the screens above are drawn from.
From the label on a pallet to the build on every terminal
Everything from the port to the database runs on the terminal and treats the network as optional. The server is where counts reconcile; a count never depends on it.
- 01 · HardwareScanners and label printersIntegrated against the facility's actual models. Two printers needed vendor-specific escape sequences, handled explicitly.
- 02 · Device layerUSB HID and serial via node-serialportA scan lands in the app with no keyboard-wedge workaround, and a label prints to the right printer without a dialog.
- 03 · EngineInventory processing on the terminalCounts complete locally, so a dropped connection doesn't stop a stock take or discard its entries.
- 04 · StateSQLite first, reconciled per movementA partial sync keeps the movements it confirmed, and pending counts are shown, never assumed sent.
- 05 · DeliverySigned auto-update channelSigned on Windows, notarized on macOS, a canary terminal before the floor, and a version pin per site.
What the floor can rely on
A count that survives the building it runs in
A dead spot doesn't lose a count
Counts are written to the terminal's own database first and reconcile per movement when a connection returns. The operator sees exactly what's pending, with nothing assumed.
A code cannot be mistyped
Scanners are read directly over USB HID and serial. There's no keyboard path for a code anymore, so there's no transcription step for an error to slip in through.
No release nobody asked for
Builds are signed and notarized, reach a canary terminal before the floor, and can be pinned per site, so an update never interrupts a peak week.
Need software that talks to the hardware on your floor and keeps counting when the signal drops? Scope your build in 3 minutes.
Scope your buildNearby engagements
Data & AnalyticsWarehouse inventory that stays accurate on its own
An inventory automation layer that reconciles counts across warehouses, forecasts replenishment, and flags discrepancies before they become stockouts.
Warehousing & Fulfillment · 13 weeks
Web PlatformsOne long form is why the device records were empty, so the record became tabs
A small desktop tool for cataloging equipment, where a device record is split into tabs so a partial entry is a normal state, never an abandoned form.
Logistics & Distribution · 5 weeks
Web PlatformsA freight portal that brings visibility to every mile
A real-time shipment visibility platform connecting carriers, shippers, and dispatchers with live tracking, geofence alerts, and automated status updates.
Freight & Trucking · 18 weeks
Let's talk
Running a large platform, shaping a first MVP, or getting a product ready for a funding round? Tell us where you are. We'll shape the process around it, and stay with you after launch.
