The Scanner Swap

The product worked. Pods were in gyms, scanning QR codes, opening doors.

Underneath, the structure was improvised in three ways the team couldn't see from inside the build:

• —The QR-code scanner — the most expensive single component in the BOM after the compute board — was sourced through a single direct purchase from a European retail vendor at €33.61/unit, flagged in the BOM itself as "always limited availability." No second source. No relationship with the manufacturer. The price was retail.
• —The incumbent software contractor's estimate to integrate a different, cheaper scanner was already in the roadmap. The number was substantial enough to gate the decision, and nobody had pressure-tested the assumptions underneath it.
• —The existing scanner driver — a single Python file, ~1,266 lines — was written tightly against one specific vendor protocol. From the outside it looked like swapping scanners meant rewriting all of it.

Three separate conversations, three separate counterparties, no single layer responsible for asking whether the assumptions stacked up.

The audit started with the BOM and the question: if your current vendor couldn't supply this scanner next month, what would it cost you?

The answer, traced through:

• —Source identified. The retail SKU was a relabel of an embedded NFC + 2D scan engine made by a Guangzhou OEM. The path from factory to gym wall was: factory → European importer → European retail listing → BOM. Two re-sellers, full retail markup, no volume discount, no committed lead time.
• —Shortlist built. Fifteen candidate suppliers vetted across two scanner families — the incumbent's supplier and a comparable alternative. Pricing, MOQ, monthly capacity, lead time, OEM-vs-trader status, and Mandarin-language quality of the technical documentation, all reviewed first-hand.
• —Direct OEM contact established. Conversations with the actual manufacturer — in Mandarin, no intermediary. Bulk pricing at 100+ units came in at roughly ~€25 / unit OEM-direct versus the €33.61 retail baseline.

Net effect: ~25% landed cost reduction, supply availability unblocked, and a direct OEM relationship that scales past 100 pods without renegotiation.

The original quote rested on a single unspoken assumption: that integrating the new scanner meant porting the existing driver — same protocol, new bytes.

Reading the existing 1,266-line driver against the new scanner's 105-page manufacturer manual produced a different finding.

The new scanner does not speak the old protocol at all. It is not configured by writing to registers over the serial line. It is configured by physically scanning a printed page of setup barcodes — interface, baud rate, prefix/suffix, NFC on/off, the lot. There is no host-to-scanner command set. There is nothing to port.

Translated into the codebase:

Roughly 80% of the existing driver can be deleted, not ported. The work that remains is small: a serial-frame parser, a Code-ID lookup table, and a one-page printed setup procedure for installation.

Defensible cost for the full swap, including architectural cleanup and rollout: €6k–€12k offshore, €10k–€16k European freelancer. The gap between that range and the original estimate isn't a pricing question — it's a structural one. Scanner integrations almost always require porting a vendor protocol; this one didn't, but that fact lived in a single paragraph of the manufacturer manual. Recognising the work was 80% deletion rather than 80% port meant reading the manual and the existing driver in the same week — which is not what an external contractor working from a written spec is usually paid to do.

This is the part of the case that generalises.

The hardware sourcing decision and the software contracting decision belonged to different conversations with different counterparties. Neither side had an incentive to question the other's framing. The supplier saw an order. The contractor saw a spec.

The single fact that collapsed the original quote — this scanner is configured by barcode, not by protocol — lived in one paragraph on page 14 of the manufacturer's manual, in dense technical English next to a diagram. It was nobody's job to read it.

Hardware companies almost always have a version of this. The structural cost is paid where two layers meet and nobody owns the seam.

• —Fluent Mandarin. The OEM's product page, datasheets, and pricing flow read directly, without translation losses or trader intermediation. The relationship was opened in the OEM's language.
• —Architecture reading. Opening the codebase and the manufacturer manual side by side, and seeing what was actually vendor-coupled vs reusable. Not theoretical — line-by-line.
• —Cross-layer view. Sourcing and software live in different rooms in most companies. They belong in the same conversation. The €20k saving lived in that conversation, not in either room.

What this kind of case usually looks like

You probably have a version of this in your own product. It tends to live in one of three places:

1. 01

   A component that is single-sourced or sourced through a re-seller because that's how it was sourced for the first prototype, and it never got revisited.

2. 02

   A scope of work that was estimated against one set of assumptions, where the underlying assumption is wrong but no one has the cross-layer view to see it.

3. 03

   An architectural seam where vendor-specific code has leaked into workflow code, so changing one supplier feels like rewriting the product.

A structural audit is usually enough to surface these. The output is a named list of dependencies and what each one would cost to break.