# ESP32 custom PCB design: a practical requirements checklist

> Prepare an ESP32 custom PCB design brief with the exact module, power requirements, GPIO map, programming access, enclosure constraints and acceptance tests.

Source: https://ohmbo.com/blog/esp32-custom-pcb-design

An ESP32 custom PCB design brief should identify the exact module, its power source, the signals your firmware uses and how the board will be programmed and tested. “An ESP32 sensor board with USB-C” leaves several decisions open. A reviewer needs enough information to check those decisions against your application and the selected hardware.

This checklist is for planning a low-voltage prototype around an existing module. It is not a reference schematic, an RF design tutorial or a claim that every ESP32 project fits Ohmbo's $149 package. Bring the working development board, module documentation, firmware configuration and enclosure drawing before requesting a layout.

## Name the module, not just the family

Record the complete module part number and revision, including the memory and antenna variant where applicable. Also name the development board you have used. The board can contain support circuitry that will not appear automatically when you move its module to a custom carrier.

Use the manufacturer's documents for that exact target. The [Espressif ESP32 schematic checklist](https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32/schematic-checklist.html) covers power, reset timing, memory, strapping pins and peripheral interfaces for ESP32. It is a useful review map, but it is not a substitute for ESP32-C3, ESP32-S3 or another target's own guidance. Source checked: 2026-10-19.

Attach a link to the relevant datasheet and the footprint source. If a part is unavailable, decide whether another variant is acceptable before routing begins. A similar name is insufficient evidence of electrical, mechanical or firmware compatibility.

## Describe power in each operating mode

Specify the input source, its voltage range and every load the board supplies. List the operating modes that matter to the prototype: startup, normal sampling, communication and sleep, if used. Provide measured data from the working setup when you have it, labelled with the conditions under which it was obtained. If a value is unknown, mark it for review.

The design brief should distinguish input power from the module's supply rail and from peripheral supplies. Ask the engineer to check the regulator, decoupling and power-up behavior against the chosen device documentation and load requirements. Copying the development board's connector without reviewing its supporting power circuit does not preserve that behavior.

For a USB-C connector, state whether it is intended for power, data, firmware loading or a combination. Request the actual implementation to be reviewed. A connector shape alone does not establish a chip's USB capabilities or the board's programming path.

## Build a GPIO and interface table

For each connection, record the module pin, firmware assignment, signal direction, voltage requirements and external circuit. Add startup constraints and whether the signal must remain accessible during debugging. Let the engineer resolve conflicts before approving the schematic.

| Item in the brief | What to provide |
| --- | --- |
| Sensor interface | Exact sensor part, bus, firmware configuration and connector pin order |
| User controls | Switch or encoder connections and the required startup behavior |
| External outputs | Connected load, control behavior and the interface circuit that needs review |
| Debug connection | Required signals, adapter and accessible connector or pads |
| Spare pins | Specific planned uses, or an explicit statement that they are unassigned |

The table is an input to review, not a suggested universal ESP32 pinout. In particular, identify any pins with boot or module-internal functions using the selected part's documentation. An example from a different board may have assumptions your design does not share.

## Leave access for programming and recovery

Document the first programming operation on a blank board. Include the firmware image, configuration, tool version, connection method and instructions. Then describe how the board can be recovered if the application does not start.

Review this with the enclosure in place. A test pad that becomes inaccessible under a module or mounting feature may not support the intended procedure. Decide whether boards are programmed before final installation, and whether later access is required.

Agree on who supplies test firmware and who performs loading. If the application depends on a private account or an external service, agree on a factory-test method that can run independently. Assign someone to supply that test build and define its acceptance criteria.

## Check module placement against the enclosure

Send the enclosure material, nearby metal parts, mounting locations and cable positions with the mechanical drawing. Wireless-module placement needs review even when the antenna is already on the module.

[Espressif's ESP32 module placement guidance](https://docs.espressif.com/projects/esp-hardware-design-guidelines/en/latest/esp32/pcb-layout-design.html#general-principles-of-pcb-layout-for-modules-positioning-a-module-on-a-base-board) discusses the base-board relationship to the antenna, clearance and the effect of the final housing. Follow the rules for the module you actually use. Do not infer a communication range from a CAD rendering or from a successful sensor read. Source checked: 2026-10-19.

This guide does not add RF design, antenna tuning or certification to Ohmbo's service scope. Confirm project eligibility with the team. Module integration questions and any additional validation must be resolved before an order is accepted.

## Write acceptance criteria before requesting a quote

Choose observable checks for the prototype: successful firmware loading, identified firmware revision, specified power-rail measurements and the intended peripheral behavior. Define the conditions and limits for each check. If wireless behavior matters, ask explicitly which checks can be supported; do not assume they are included.

The [prototype testing guide](/blog/pcb-prototype-testing) explains how a test plan becomes a record for each board. A boot log or sensor identity response is a narrow result, not proof of measurement accuracy, wireless range or long-term reliability.

Use the complete BOM and requirements to check [pricing and kit limits](/pricing). The $149 Proto Kit covers five eligible low-voltage DC, two-layer boards within the stated specifications, including a $10-per-board component allowance. Four- and six-layer designs require review and a separate quote. Shipping and import duties are extra, confirmed before payment. An ESP32 label alone cannot establish eligibility.

## Questions about ESP32 custom PCB design

### Can I reuse a layout from another ESP32 variant?

Use it only as a reference until the engineer checks it against the exact module's documentation, footprint and interface requirements. Family naming does not establish pin or circuit compatibility.

### Does my board have to use four layers?

Layer count depends on the actual design and its constraints. Ask for an engineering decision rather than choosing solely to fit a price. Read the [two-layer and four-layer guide](/blog/2-layer-vs-4-layer-pcb); multilayer work requires a separate quote.

### Are the boards in Ohmbo's gallery manufactured examples?

The [board gallery](/boards) contains design demonstrations. Its images do not establish physical manufacture, functional test results or an exact configuration you can order without review.

## Send a reviewable ESP32 brief

An ESP32 custom PCB design request becomes concrete when the module, power, interfaces, programming and acceptance criteria agree. Send that package through [contact](/contact). Keep unresolved details visible so the engineer can confirm feasibility and the order scope before production is scheduled.