From ESP32 Dev Board to Custom PCB: What Actually Changes

Short answer: moving from an ESP32 dev board to a custom PCB means taking over everything the dev board quietly did for you. That is the power supply, the boot and reset circuit, the USB-to-serial bridge, antenna clearance and a programming method. Most first-spin failures come from those five things, not from your own circuit.

A dev board is a very forgiving place to build a prototype. It takes 5 V from USB, regulates it, handles reset and boot mode for you, and puts the antenna somewhere sensible. Once the firmware works and the sensors are wired up on a breadboard, the next step feels small: put the same parts on one board.

It isn’t small. Here is what changes, roughly in the order it tends to bite.

1. Module or bare chip

The first decision is whether to put an ESP32 module (like the ESP32-S3-WROOM-1) on your board or the bare chip.

For almost every product we build, the answer is the module. It gives you:

• The crystal, flash, and (on some variants) PSRAM already integrated and tested
• An RF matching network and antenna that Espressif has already tuned
• Existing radio certifications (FCC, CE and others) that your product can build on

The bare chip makes sense when you are making tens of thousands of units, need a very small board, or need an external antenna design. You then own the crystal layout, the RF matching, the flash, and a lot more certification work. That is a real project in its own right.

Pick the module variant carefully too. The suffix tells you the flash and PSRAM size (for example, N8R8 means 8 MB flash and 8 MB PSRAM). On the ESP32-S3, modules with octal PSRAM use GPIO35, 36 and 37, so those pins are not available to you. That is easy to miss when you copy a pin map from a dev board that used a different variant.

2. Power: the part dev boards hide best

Many cheap dev boards use an AMS1117 regulator. It works on the bench, but it is a poor choice for a product:

• Dropout is around 1 V, so it needs well over 4 V in to give you a clean 3.3 V out. A LiPo battery spends most of its life between about 3.6 V and 4.2 V.
• Quiescent current is several milliamps, which wrecks battery life on a device that sleeps most of the time.

The ESP32 draws short current spikes of several hundred milliamps when Wi-Fi transmits. Espressif recommends a supply that can deliver at least 500 mA. If your regulator or battery path can’t handle those spikes, you get brownout resets that only happen in the field, usually when the signal is weak and the radio is working harder.

What to do instead:

• Use a low-dropout regulator with low quiescent current, or a buck-boost converter if you run from a single LiPo cell and want to use the whole battery
• Put decoupling capacitors right next to the module’s 3V3 pin (a 10 µF and a 0.1 µF is the usual starting point), plus bulk capacitance near the regulator
• If the device runs on battery and USB, design the switch-over properly with a charger IC that supports power-path management, instead of tying everything together and hoping

On the S3 motion logger board we are designing for our own portfolio (USB-C, LiPo charging, IMU and microSD), the power section took more thought than the rest of the schematic combined. The microSD card has its own write current spikes. Those land at the same time the radio might be transmitting.

3. Boot, reset and strapping pins

On a dev board, you press a button or the USB bridge toggles reset for you. On your board, you need to do it yourself:

• EN (reset) needs a pull-up and an RC delay so the chip starts only after the supply is stable. Espressif’s hardware design guidelines recommend a 10 kΩ pull-up and a 1 µF capacitor as a starting point.
• GPIO0 selects download mode at boot. Add a button or at least a test pad for it.

Then there are the strapping pins. They are sampled at power-up and decide things like boot mode and, on some chips, flash voltage. If you hang a sensor, LED or pull resistor on one of them, the chip can refuse to boot, or boot only some of the time.

The classic example is GPIO12 on the original ESP32. If something pulls it high at boot, the chip sets the flash voltage to 1.8 V. With the usual 3.3 V flash, the board won’t boot. On the ESP32-S3, the strapping pins are GPIO0, GPIO3, GPIO45 and GPIO46. Check the datasheet for your exact chip and keep those pins free of anything that could pull them the wrong way at power-up.

4. USB: the bridge chip you may not need

Most dev boards have a USB-to-UART bridge (CP2102, CH340 and similar) plus two transistors that let the flashing tool toggle reset and boot mode automatically.

If you are using an ESP32-S3 or ESP32-C3, you may not need any of that. Both have a built-in USB Serial/JTAG controller on GPIO19 and GPIO20 (S3) that can flash, debug and give you a serial console with no extra chip. That saves cost and board space.

If you use a USB-C connector, two details cause a surprising number of dead boards:

• CC1 and CC2 each need a 5.1 kΩ pull-down to ground. Without them, a USB-C to USB-C charger or laptop port will not supply 5 V at all. A USB-A to USB-C cable will still work, which is why this bug often survives until a customer plugs it in.
• Add ESD protection on the data lines and VBUS. The connector is the part people touch.

Route D+ and D- as a short differential pair over a solid ground plane, and keep them away from noisy switching regulators.

5. Antenna placement and layout

The module’s PCB antenna needs clear space to work. Espressif’s guidelines are specific, and they matter:

• Put the module at the edge of the board, with the antenna either overhanging the edge or sitting over an area with no copper on any layer, including ground
• Keep metal parts, batteries, connectors and the enclosure’s metal parts away from the antenna area
• Think about the enclosure early. A metal case, or a hand holding the device at the antenna end, can cut range dramatically

A layout that ignores the keepout will often still work on your desk. It just has a fraction of the range, and you find out in a warehouse or a field.

For the rest of the layout, a 4-layer board with a solid ground plane makes life easier for anything with radio, USB and switching regulators on it. Two layers can work for simple boards, but they leave less room for error.

6. Programming and testing in production

On a dev board you flash over USB with the board in your hand. In production, think about how every unit gets firmware and gets tested:

• Add test pads for 3V3, GND, TX, RX, EN and GPIO0 (or the USB pins) so a pogo-pin jig can flash and test boards before they go into the enclosure
• Decide on secure boot and flash encryption before production. They are set using eFuses, which are one-time programmable. Getting them wrong can permanently lock a board
• Plan OTA updates from day one: a partition table with two app slots, and rollback if the new firmware fails to start. You can’t fix a fleet with a USB cable

7. Manufacturing and the bill of materials

A schematic that works is not yet a board someone can build:

• Check part availability before you commit. A part with no stock or a long lead time can hold up a whole production run. Most assembly houses publish lists of parts they stock, and designing around those saves cost and time
• List alternates for passives and common parts in the BOM
• Run design-for-manufacture checks with your fab’s rules (trace width, spacing, via size, solder mask) before you send files
• Order a small first run, five to ten boards, expecting a second revision. Very few boards are right on the first spin

8. Bring-up: the first power-on

When the boards arrive, don’t plug them into USB and hope:

1. Inspect the board under magnification for solder bridges and part orientation
2. Power it from a current-limited bench supply and check each rail before connecting anything else
3. Flash a minimal firmware that only blinks an LED and prints over serial
4. Bring up each peripheral one at a time: IMU, storage, radio, then everything together
5. Measure sleep current. It is the number most likely to be wrong, and the one battery products live or die by

Certification, briefly

Using a pre-certified module helps a lot, but it doesn’t mean your product is automatically compliant. The module’s radio certification covers the radio as long as you follow the antenna guidelines. Your finished product still usually needs emissions testing for the rest of the circuit (for example, FCC Part 15 unintentional radiator rules in the US). Design with that in mind: clean power, short high-speed traces and a good ground plane all make the test lab visit shorter.

Where we come in

We design custom ESP32 boards in KiCad, write the firmware, and build the app and cloud back end the device talks to. If you have a prototype that works on a dev board and need to get it onto a real PCB, or a first board that doesn’t behave, see our embedded systems and IoT development service.

If you are still deciding whether the idea works at all, a hardware proof of concept on a dev board is the cheaper first step. And if you are choosing a firmware framework for the product version, read our comparison of ESP-IDF vs Arduino for a commercial product.