The Problem I Was Asked to Solve
Last fall I opened an RFQ for project c300. The product description in our PLM said platinum blood pressure monitor. It was a home telehealth device with a color screen, Bluetooth to a companion app, and Wi-Fi for cloud uploads. The prototype ran on an Espressif module, and I needed production pricing for 25,000 units, plus a pilot order of 2,000.
The first red flag was hiding in plain sight. The BOM line said espressif inc wifi and nothing else. That is like ordering a car by body style. Espressif makes a wide range of Wi-Fi modules, and they are not interchangeable. Engineering called the product c300, manufacturing called the assembly C300, and marketing had already typed platinum onto the box. Nobody was using one unambiguous part number.
Unit Price Made Me Want the Cheaper Module
When the quotes came in, the lowest-priced module was based on the ESP32-C3. That is a proven chip, and I don't want to imply it's weak. It has a mature SDK, decent power consumption, and years of real field use. The catch is that it's a 2.4 GHz-only device. The c300 product needed to work in homes where the 2.4 GHz band is crowded with baby monitors, smart TVs, microwaves, and neighbors' access points. The engineering lead preferred the ESP32-C5 because it supports 5 GHz and Wi-Fi 6. The price difference was real. At 25,000 units, the C5 might cost $30,000 more. For a 40-person company, that's a serious line item.
So I did the careful buyer thing. I followed the espressif esp32-c5 mass production announcement, checked distribution stock, and called our rep. The official news sounded good, but the first production allocation was already claimed. Mass production was real; availability for a small customer like us was not immediate. That delay is also a cost, even though no one invoices for it.
The Hidden Cost That Changed My Decision
Here is where I have to admit something. I almost ignored the difference because the ESP32-C3 is technically adequate for many BLE and Wi-Fi home devices. The reason I didn't ignore it is a support log from a prior product. We had a health device that paired to a cellular flip phone as a gateway. The support queue contained a repeated question: how to turn on verizon flip phone. The phone had gone to sleep. The screen was dark. The patient thought it was broken. The blood pressure reading stayed in the monitor. The patient called our support line. We walked them through pressing the power button again, but the confidence was gone.
The lesson wasn't about flip phones. It was about adding a second device, a second power button, and a second charging cable into a care product. A low-cost radio choice can force a user into a technical task. If the c300 monitor could not connect reliably over 2.4 GHz, the user would not know how to change the router channel. They would know that their expensive blood pressure monitor did not work. That is a support cost, a return cost, and a clinical data gap.
What I Learned About Total Cost From This Project
If the only metric is unit cost, the ESP32-C3 looked great. If the metric is total cost of ownership, the comparison changes. Total cost includes board space, antenna matching, battery consumption, test time, certification, module lifecycle, OTA updates, and every support call. It also includes what happens if a module goes end-of-life two years into a product that is supposed to last five. I built a small cost model after this project, and I now insist that engineering fill it out before the schematics are locked.
The biggest question in that model is not which chip is cheapest. It is what happens on the 1-in-100 unit that fails at 3 a.m. in someone's home. The answer determines the real price.
A Small Buyer's Rules for Module Selection
My company is small, so our purchase orders are small at first. Over the years I've learned that any supplier that treats a 1,000-piece pilot like a waste of time will also miss your follow-up when you need 10,000 pieces. I stopped apologizing for small orders. If a vendor's smallest package is bigger than my need, I move on. Good vendors are usually willing to work with small customers if the product has a roadmap and if you can communicate clearly.
- Ask for the module's mass-production status in writing.
- Ask whether the module revision you qualify is the only revision shipping.
- Ask for the distributor's allocation policy if the chip goes into shortage.
- Do not let a buyer choose a module alone. Engineering, procurement, test, support, and certification all have to be in the same room.
Honestly, I'm still not sure why deep BOM conversations only happen after a product fails. My best guess is that unit cost is easy, while TCO is messy. Messy decisions are the ones that protect budgets.
Bottom Line: Cheap Is What You Can Actually Ship
I did not approve the ESP32-C3 module for c300. I also didn't approve the most expensive module in the comparison. I approved the module that solved the real problem: reliable uploads, stable supply, enough stock for the pilot, and a support team that would not have to turn patients into IT technicians.
So glad I waited to sign that PO. We almost went with the lower-priced part just to hit a quarterly budget target. The redesign would have been embarrassing and expensive. Instead, the c300 remains a work in progress, but it won't require anyone to learn how to use a cellular flip phone just to take a blood pressure reading. If I did my job right, the next support ticket will be about the Wi-Fi password, not the hardware.
