Every WMS deployment we've ever lost ended up on the same rock: barcode scanners.
The customer is excited about the software. The pilot is going well. Then someone — usually IT or procurement — asks how many scanners they need to buy. The answer is a number that's bigger than they were expecting, plus a hardware-onboarding project, plus a charging-station SKU, plus a long debate about which model is "best", plus a six-month break-fix budget. By the time the scanners arrive, the project sponsor has moved on and the warehouse has gone back to clipboards.
We watched this happen enough times that we sat down and asked the obvious question: do we actually need scanners?
What scanners are for, mechanically
A barcode scanner does three things that matter in a warehouse: it's robust (drop-tested, glove-friendly, IP-rated), it's fast (sub-second resolution from awkward angles), and it's hands-free-adjacent (pistol grip, ring scanner, glove-mounted variants).
For decades those three properties combined were impossible to get any other way. A 2010-era smartphone camera with an early-decade barcode SDK was slower, less reliable, and much less rugged than a dedicated scanner. So the scanner won, and the WMS market shape was set: every operator gets a scanner.
We're not in 2010 anymore. A 2024 mid-range Android phone has a 50-megapixel main sensor, a separate macro sensor, an autofocus motor that locks in 200ms, and is calling on AI vision models that resolve a tilted, half-obscured barcode faster than the user can square it up. Drop-test ratings on consumer phones are better than they've ever been. Cases and tethers solve the rugged-handling gap. Cost is ₹15-25k for a perfectly capable phone that the operator may already own, versus ₹40-80k for a dedicated handheld.
The scanner advantage is now mostly in two places: the physical trigger (one button, no aiming) and the workflow some operators have built around it (point-pull-look-up-next). Both are real, but they're not insurmountable.
The bet we made
When we built SourceForge AI Mobile WMS for Business Central, we decided the default deployment would be camera-first on whatever Android or iOS phone the operator already has. Bluetooth scanners are supported as an optional accessory for the specific operators or workflows where the physical trigger genuinely matters — packing stations doing fifteen scans a minute, high-volume sortation lines.
This sounds incremental but reshapes the deployment economics. The hardware project disappears. There's no minimum order quantity for scanners. There's no IT-managed device fleet conversation. The pilot can run on whatever phones are in the room, with the same software. The "buy scanners" conversation gets deferred until after the warehouse is already running on the software, at which point it's a specific decision about specific workflows rather than a blanket capex requirement.
What had to be true on the technical side
Camera-first only works if three things are true: the resolution is fast and accurate, the workflow is hands-free-adjacent, and the device is reasonably secure.
Resolution. We use a combination of an on-device barcode SDK (for clean, well-positioned barcodes — the common case) and an Anthropic Claude vision call (for the messy cases — tilted, partially obscured, hand-written labels, faded receipts). The on-device path is sub-200ms. The Claude path is 2-4s but only fires when the on-device path fails. In production, ~95% of resolutions are on-device. The 5% that go to Claude would have required manual entry on a dedicated scanner.
Hands-free. This is where the physical trigger genuinely matters and where we had to think hardest. Two answers. First, we added a voice-directed retrieval mode — the operator says "next" between picks, the app advances. Second, we built an AR overlay that highlights the target bin as the operator walks the aisle; the camera is already up, and the resolve happens passively as they get close. Together these cover most of the workflows where "thumb a trigger" was the legacy answer.
Security. Consumer phones running BYOD aren't acceptable to most warehouse customers. We layered MASVS-L2 mobile hardening into the app: certificate pinning with pure-Dart SHA-256, biometric step-up (Face ID / Touch ID / fingerprint) for high-risk actions like cycle counts and write-offs, strict-mode jailbreak and root detection that hard-blocks app launch on compromised devices. Microsoft Entra ID OAuth2 via flutter_appauth for sign-in. The combination meets the security bar of most enterprise IT teams without needing dedicated devices.
What we learned in pilots
Three things, none of which we expected.
Operator adoption is higher than with scanners. New staff come on board faster because they're using the device interface they already know. Older staff who'd been resisting "more technology" turned out to be resisting more new technology — using their existing phone is fine.
The AR overlay is the killer feature, not the camera. We expected the value to be in the camera-replacing-scanner story. The actual feedback from supervisors is overwhelmingly about the AR bin-highlight reducing wrong-bin picks for new staff. The camera-as-scanner is table stakes; the AR layer on top is the multiplier.
The 5% Claude path is the trust-builder. Customers liked the on-device resolution well enough, but the moment that turned scepticism into enthusiasm was always the same: an operator pointed the camera at a torn, water-damaged manufacturer label that no scanner could have read. The Claude call resolved it in three seconds. The operator said "huh," put it in the right bin, and moved on. After watching that happen twice, every customer signs off.
What we don't claim
Camera-first isn't the right answer for every warehouse. If you're running a sortation line doing eighteen scans per minute for an eight-hour shift, you want a glove-mounted ring scanner — no phone interface beats that throughput for that specific workflow. If you're running in a sub-zero cold-store environment where consumer phone batteries die in twenty minutes, you want ruggedised scanners. We support both — the same software runs on either input device.
The point isn't that scanners are obsolete. The point is that they should be a deliberate choice for specific workflows, not a blanket prerequisite for the entire deployment. Treating them as a prerequisite is the failure mode that kills WMS projects, and removing that prerequisite is the architectural decision that lets the rest of the project succeed.
The broader pattern
There's a pattern here that goes beyond WMS. Most B2B software products were architected when one of their assumptions — about hardware, about connectivity, about computing cost, about AI capability — was a constraint. The constraint disappears, but the architecture doesn't. The product keeps shipping the workaround long after the underlying problem is gone, and customers keep paying for it.
Scanner-first WMS is one of those frozen assumptions. The constraint that made it correct is gone. The architecture that survives that change is camera-first software with optional scanner support, not the inverse. That's what we built; that's the bet.