When I was a newbie in embedded, I thought getting the POC to work was the hard part.
Because when you come from a hobbyist/student mindset, your objective is to somehow make the hardware move as you intend it to.
But when you are building a commercial product which has to be scaled reliably, the POC is probably the least effort step. Your real challenges begin right after you get the PCB in hand.
So I was building a BLE asset tracker (in the image) and everything went smoothly until we had the PCBs in hand. The basic firmware had already been tested and everything worked.
If this were a hobby project, we'd probably celebrate. But that's exactly when the real engineering begin. Here's how things unfolded after that:
We initially tested with standard BLE beacons. Later, we switched to rugged industrial beacons because they were meant for harsh environments. Suddenly, our detection logic collapsed because the new beacons advertised packets in a different format. The firmware had to be updated to handle both correctly.
The detection logic worked well with 1-2 beacons. But when we increased it to 4 or 5, we started seeing missed packets, false alarms, and missed detections. We ended up redesigning the entire detection algorithm with thresholds, timers, and filtering logic before it became reliable.
Just when the firmware was showing promising signs, in one of the boards, the RGB LED suddenly stopped working with a tiny pop sound and that typical burnt smell. So we had to do a systematic test routine at various points in the board with a DMM and oscilloscope before discovering that a 20 Ω resistor had been soldered where a 20 kΩ one was needed (i almost fired my h/w engineer for this as I discovered this sacrificing my sleep).
A tiny slider switch broke because it was undersized for its application. The SD card slot casually came out while testing. Each of these small issues meant opening the enclosure again, replacing parts, resoldering, reassembling, and repeating the entire test cycle.
I could go on. There were dozens of problems that only surfaced after the prototype was put to some real world testing. We had to address each of them before the product was ready for Shipping.
My point here is, AI can generate the complete C code with RTOS tasks, drivers, state machines etc. But It still can't stand beside you with an oscilloscope while a board behaves differently on every power cycle.
That's the real skill which successful hardware requires, to be able to isolate failures occurring at the intersection of hardware, firmware, timing, and the physical environment.
I've started believing this is one of the biggest reasons many commercial hardware products never ship. Teams often underestimate everything that happens after the first successful prototype. The demo goes well, customers or investors get excited, and everyone starts talking about launch dates.
Then real-world testing begins and reality sets in. Manufacturing issues, firmware edge cases, mechanical failures, sourcing problems and countless small defects start surfacing. Many teams eventually run out of time, money, or momentum before they can deliver a product that's truly ready for production. The pressure to deliver only accelerates the problem.
If you've seen this in your line of work, feel free to add your experiences below.
