Your Espressif IoT device resets every time a motor kicks in. The code is fine. The wiring is fine. On the bench, it works. In the field, it dies. I know that feeling. In 2022, I shipped 50 units that all did exactly that. Every one came back.
The Surface Problem: It Worked on My Bench
Here's what I told myself: “The code is fine. The Wi-Fi connects. The sensor reads correctly.” All true. The failure only happened when a 12V DC motor started. The ESP32 reset, the system rebooted, and the data gap looked like a software bug. For three days, I treated it as a software bug.
It wasn't.
The Deeper Problem: A Radio Is Not a Microcontroller
An ESP32 is a microcontroller, yes. But it's also a radio. In the past, Wi-Fi was a separate module bolted onto a board. Today, the radio and the CPU are on the same die. That changes everything. When Wi-Fi transmits, current draw jumps in short bursts. The typical current number in the datasheet doesn't show the peak. If your regulator is too small or your decoupling is missing, the voltage sags and the chip browns out. The code works. The power rail doesn't.
Why does this matter? Because the failure mode looks like a software glitch. It isn't. It's a power problem wearing a software mask.
Here's the embarrassing part. My regulator was rated at 250 mA. The average current draw looked fine. I even clipped my Fluke 117 multimeter to the rail and saw 3.3V, steady. The 117 multimeter is a good meter, but it gives you an average. It doesn't catch microsecond dips. On the bench, the display was a Nokia 3310 LCD (yes, that old LCD), and when Wi-Fi transmitted, I could see the contrast flicker. I ignored it. I told myself it was noise. I should have listened to the hardware instead of the multimeter.
Look, I'm not blaming the meter. I'm blaming my mental model. I was treating the board like a static circuit. A radio is a dynamic load.
What Most People Won't Tell You
Here's something vendors won't tell you: most “ESP32 won't work” debugging threads end up being power-related, not code-related. But that's hard to see when the library examples all run on a bench supply with a clean USB source and a dev board. Put the same chip on a custom board with a cheap LDO and a long antenna trace, and the whole design is on the edge.
The Arduino ecosystem hides a lot of the chip's behavior. ESP-IDF gives you better control and clearer low-level messages, but it's more work. If you start with Arduino and never read the ESP-IDF documentation, you're building on assumptions. That doesn't always fail. But when it fails, it looks like a ghost.
The Cost of Ignoring It
Let's make it concrete. The first batch was 50 PCBAs. Between components, assembly, and prototyping, I had roughly $3,200 in materials. Then the customer's deadline: one week. Then the credibility hit. I had the refund conversation twice. The mistake also cost me a future project with that client—they didn't say no, but they stopped calling. That's harder to calculate.
The fix was not a code patch. It was one 470 µF bulk capacitor near the power input, a better LDO with more output current, and a ground plane under the ESP32. Also, antenna clearance. Total extra cost per board: about $1.50. The second batch passed. I made a checklist after that.
According to Espressif's Hardware Design Guidelines (docs.espressif.com), decoupling capacitor placement and antenna clearance are not suggestions. They are requirements. I didn't read them carefully until the third iteration. That's on me.
The Pattern I've Seen Since Then
It took me three years and about 50 units to understand that the difference between a working prototype and a working product is usually power design, not code. After five years and roughly 40 custom Espressif IoT device builds, I've come to believe that the three classic failure categories are: power that can't handle radio bursts, reference designs that are “close enough,” and software built on too many layers of abstraction. The last one is ironic, because the ESP32's popularity comes from that abstraction.
One caveat: my experience is mostly sensor nodes and connected controllers in small production batches. I have not designed high-availability industrial gear. If you're doing safety-critical systems, you need different expertise—probably someone who does compliance testing, not someone from the internet.
What I Do Now (The Short Version)
Start with the power budget. Read the hardware design guidelines. Measure transients with a scope, not only a 117 multimeter. Test the radio under full load from day one. Keep the antenna away from copper pours. Use a regulator with enough margin. That's it.
And know what your vendor is good at—and what they're not. If you need Wi-Fi/BLE SoC design, an Espressif specialist is a good fit. If you need enterprise network infrastructure, that's a Cisco conversation. The “Espressif vs Cisco” question is really a “microcontroller vs network appliance” question: different tools, different problems.
These days, I'd rather work with a specialist who knows their limits than a generalist who overpromises. That applies both ways.
