Supplier Lock-In Is an Architecture Problem, Not a Procurement Problem

The Moment Most Companies Discover the Problem

It usually happens at the worst possible time. A key component goes end-of-life. A geopolitical event disrupts a supplier. A quality failure in production forces a redesign. And the engineering team discovers that changing the component means rewriting the firmware, re-certifying the product, and potentially re-tooling the enclosure.

This is supplier lock-in. And almost every hardware company I work with has it — often without knowing it.

The standard diagnosis is that it is a procurement problem. The company bought from a single source, failed to qualify alternatives, or did not build a dual-source strategy. All of that may be true. But it is the wrong level of analysis.

Why Procurement Cannot Fix It

Procurement can find alternative suppliers. What it cannot do is make those alternatives drop-in replacements. If your firmware is written directly against a vendor's proprietary SDK — if your HAL (Hardware Abstraction Layer) is the vendor's HAL — then switching suppliers means rewriting software, not just reordering components.

This is the architectural lock-in. It happens because hardware teams, under time and cost pressure, take the path of least resistance: they use the vendor's reference design, the vendor's SDK, and the vendor's example code. The product ships. It works. And the dependency is invisible until it is not.

The Structural Question

The right question is not "do we have a backup supplier?" It is: "How many hours of engineering work would it take to swap this component for an alternative?"

If the answer is more than a few days, you have an architectural problem. The component has leaked into your business logic. Your system is not modular — it is monolithic at the hardware boundary.

What Good Architecture Looks Like

A well-architected hardware-software system treats the hardware layer as a replaceable dependency. This means:

• Defining interface contracts at the hardware boundary: what does the rest of the system need from this component? A network connection. A sensor reading. A storage write. Not a specific chip.
• Implementing a thin abstraction layer that translates between those contracts and the specific vendor SDK. This layer is the only code that knows about the specific chip.
• Validating the abstraction by ensuring the system can be compiled and tested against a mock implementation — before the real hardware is available.

This is standard software engineering practice. It is applied routinely in cloud software. It is applied far less often in embedded firmware, where the culture prioritizes performance and resource constraints over replaceability.

The China Dimension

The problem is particularly acute for companies sourcing from China, for two reasons.

First, Chinese component vendors — particularly in the cellular IoT module space (Quectel, SIMCom, Fibocom) and the SoC space (Espressif, Rockchip) — provide deeply integrated SDKs that are designed to make their components easy to use and hard to replace. This is not malicious; it is good product strategy on their part. But it means the default path leads directly to lock-in.

Second, the documentation gap makes it worse. Chinese vendors publish two tiers of documentation: a high-level English datasheet for international customers, and a deep technical reference — application notes, register maps, undocumented features — that exists only in Mandarin. Engineers working from the English documentation are working from an incomplete picture. They make architectural decisions based on what the component appears to do, not what it actually does.

What To Do About It

If you are in the design phase: define your hardware interface contracts before you choose your components. This forces you to think about what the component needs to provide, not which specific chip you are going to use.

If you are already in production: do an architectural dependency audit. Map every place in your codebase where vendor-specific APIs, types, or constants appear. That map is your lock-in exposure. Prioritise the highest-risk dependencies — the ones where an alternative would require the most rewriting — and build abstraction layers around them incrementally.

The goal is not to eliminate Chinese suppliers. For most hardware companies, that is neither realistic nor desirable. The goal is to ensure that your architectural decisions do not make you a hostage to any single supplier's roadmap, pricing, or geopolitical situation.

That is an architecture problem. And it has an architectural solution.