ESP32 Dev Board vs Custom PCB: When to Switch

October 12, 2026

Every ESP32 product starts on a dev board. That is the right way to start — you get a working platform in minutes and can focus on firmware and the product idea. Then comes the question that stalls a lot of projects: when should we stop using dev boards and build an esp32 custom pcb?

The honest answer is "when the dev board starts blocking you." But it is worth understanding exactly what a custom board gives you, what it costs, and what changes afterward.

What the dev board gives you (and why it is temporary)

An esp32 development board is a complete, tested ESP32 system with power regulation, a crystal, decoupling, debug access, USB, and often extra flash and sensors you do not need. That convenience is exactly why it cannot be your product:

It is larger than your product can accommodate.
It has connectors and components your product does not need, which costs money and space.
It is not optimized for power, so battery life suffers.
It cannot be panelized or assembled the way a production board can.
It does not fit your enclosure.

The dev board is a development tool. The product needs a board designed for it. Even the best esp32 dev board is a general-purpose platform; your product is a specific one.

The signals that it is time to switch

You are ready for an esp32 custom board when several of these are true:

The enclosure and form factor are defined and the dev board does not fit.
You need to reduce power consumption meaningfully for a battery product.
You are going to production and need a manufacturable board.
You need specific connectors, sensors, or interfaces the dev board lacks.
The dev board's cost matters at your volume (it often dominates at scale).
You need certification, which a dev board cannot give you.

If none of these are true yet, keep developing on the dev board. There is no prize for building a custom board early.

What a custom PCB gives you

Size and shape that fit your enclosure.
The exact interfaces your product needs, and nothing else.
Power design optimized for your battery or power source.
Manufacturability — panelization, assembly, and test.
Certification path — a board designed for it, not a dev board that cannot be certified.
Cost control at volume.

A custom board is not just smaller; it is designed for a purpose the dev board never had. Once you have a custom esp32 board, the whole product — enclosure, assembly, certification — becomes coherent in a way a dev-board product never can.

What it costs

A custom ESP32 board has real costs, and they are worth understanding before you commit:

Design cost — schematic capture and layout, either in-house or outsourced.
Prototype cost — fabrication and assembly of the first boards.
Iteration cost — rarely does the first board work perfectly; plan for at least one revision.
NRE — stencils, fixtures, and setup for production.
Time — weeks, not days, from design start to a working prototype.

The trade-off is between paying now for a board designed for your product, and paying later in the form of a product that does not fit, does not last, or cannot be made.

What changes after the switch

You own the board. After the switch, changes cost more and take longer, because they involve redesign rather than rewiring. This is why the design should be done once, carefully.

Debug is your responsibility. The dev board had debug built in; your custom board must bring it out explicitly. Never skip this.

You become the integrator. The dev board hid a dozen details — power, clocking, boot configuration. Your board has to handle them. (If you are coming from the classic ESP32, our guide on moving from a dev board to production covers this in detail.)

Manufacturing enters the picture. Component sourcing, assembly, and test become part of your workload.

A decision framework

| If… | Then… |

|---|---|

| Still iterating on firmware | Stay on the dev board |

| Enclosure defined, dev board does not fit | Switch |

| Battery life is a requirement | Switch |

| Going to production | Switch |

| Volume is tiny and form factor is flexible | Maybe stay on a module-based board |

| Need certification | Switch |

The most common mistake is switching too early — building a custom board before the firmware and product are ready, then redesigning it when requirements change. The second most common is switching too late — trying to ship a product built from dev boards. Both mistakes cost money; the first costs more, because a redesign touches everything.

A cost of ownership comparison

The dev board and the custom board are usually compared on unit price, which is the least interesting number. A fuller comparison covers the whole life of the product:

| Cost element | Dev board | Custom PCB |

|---|---|---|

| Unit cost at low volume | Low | Higher (NRE spread thin) |

| Unit cost at high volume | High and fixed | Lower and falling |

| Design effort | None | Significant, one-time |

| Enclosure fit | Poor or none | Exact |

| Power optimisation | None | Designed in |

| Certification | Not possible | Designed in |

| Assembly | Manual | Automated |

| Field failure profile | Generic | Controlled |

At ten units, the dev board wins on every line that is measured in dollars. At ten thousand units, the custom board wins on unit cost, enclosure, power, and certification. The crossover is somewhere in the hundreds to low thousands, and where exactly depends on the product.

What the transition actually looks like

Moving from a dev board to a custom board is not one step; it is a short project with a recognizable sequence:

Freeze the requirements — the interfaces, the form factor, the power budget, and the certification target.
Capture the schematic, starting from the reference design and the dev board you validated.
Lay out the board, with the RF and the power treated as first-class.
Fabricate and assemble a small number of prototypes.
Bring up and iterate, expecting at least one revision.
Lock the design and move to production.

Most of the schedule risk lives in step three and step five, which is why the requirements should be frozen before either begins.

The mistakes that cost the most

Three mistakes account for most of the pain in this transition:

Switching before the requirements are stable. A custom board built on shifting requirements becomes two or three custom boards, and the cost is not linear.
Forgetting debug access. A board with no probe points is a board you debug by soldering wires onto pads and hoping.
Treating the first board as production-ready. The first board is a prototype, even when it comes from a professional design. Plan for one revision as a normal cost, not a failure.

None of these are exotic. They are the ordinary reasons projects slip, and they are all avoidable with a little discipline up front.

Deciding with numbers instead of feelings

The switch decision is often made emotionally — someone is frustrated that the dev board will not fit, or someone is excited about building hardware. It goes better with numbers. Write down:

The volume you expect in the first year and the second.
The dev board's cost per unit at that volume.
The estimated design cost, in-house or outsourced.
The expected number of revisions and their cost.
The value of the features the custom board unlocks — size, power, certification.

Those five numbers usually point clearly in one direction, and having them written down makes the decision defensible to whoever is paying for it.

A staged path that reduces risk

The switch does not have to be all-or-nothing. A staged path reduces the risk of switching too early or too late:

Prototype on the dev board, to prove the concept and the firmware.
Build a first custom board that is close to the dev board in function, to prove the design process.
Refine the board for size, power, and the enclosure once the product is stable.
Lock and produce when the requirements have stopped moving.

Each stage is a smaller commitment than the last rewrite, and each produces something usable. A team that follows this path rarely finds itself redesigning from scratch, because each board is built on a validated one.

Keeping the dev board honest

Even after switching to a custom board, the dev board has a role, and it is worth keeping one around:

As a reference when the custom board misbehaves, since it is a known-good platform.
For firmware development while the custom board is being revised.
For comparison testing, to separate a firmware problem from a hardware problem.

The dev board is not the enemy of the custom board; it is the baseline. A team that keeps a working dev board nearby diagnoses hardware problems faster, because it always has a comparison that is not in doubt.

A last look at the decision

The dev board versus custom PCB decision comes down to a single question: is the dev board still the cheapest way to make progress? While the product is being defined and the firmware is being written, it almost certainly is. Once the product is defined and the constraints are real — size, power, enclosure, certification, cost — the custom board becomes the cheaper path, even though it costs more in the moment.

Answering that question honestly, with the numbers written down, is what separates a team that switches at the right time from one that switches too early and rebuilds, or too late and cannot ship.

Where the real risk sits

The dev-board-to-custom transition feels risky because it is the moment the product stops being a prototype. In practice, most of the risk is concentrated in two places: the requirements not being frozen, and the design not being reviewed. A transition with frozen requirements and a reviewed design is ordinary engineering. A transition without them is a gamble dressed up as a plan.

A final thought on timing: the cost of switching a little late is usually small — you ship a slightly larger product for one more cycle. The cost of switching too early is large, because a redesign touches the enclosure, the certification, and the firmware. When in doubt, wait until a requirement is genuinely blocking you, then switch with the requirements frozen and the design reviewed. That is the path that produces the fewest surprises.

What the custom board unlocks beyond size

It is easy to think of the custom board as "the smaller dev board," but the switch changes what the product can be:

Power that lasts. A custom board can switch off subsystems the dev board leaves on, turning weeks of battery life into months or years.
An enclosure that fits. The board is designed to the enclosure, so the product looks and feels intentional rather than adapted.
A certification path. The dev board cannot be certified as a product; a custom board is designed to be.
A manufacturable assembly. The board can be panelized, placed, and tested at volume, which the dev board cannot.
A cost curve that falls. The dev board's cost is fixed; a custom board's cost falls with volume.

None of these is dramatic on its own. Together they are the difference between a prototype and a product, which is the real content of the switch.

The hidden cost of staying too long

The advice to avoid switching too early is right, but the opposite mistake has a quieter cost. A team that ships a product built from dev boards is paying, on every unit, for a board that was never meant to be sold. It is paying in unit cost, in enclosure compromises, in battery life that disappoints, and in a product that cannot be certified in its own right.

Those costs do not appear on the project plan; they appear on the balance sheet, one unit at a time. A team that waits too long is not being cautious; it is accumulating a tax it did not budget for. The signal to watch is not "can we afford to switch?" but "are we now paying, every month, for not having switched?" When that second question turns positive, the decision has already been made.

Closing: a product, not a prototype

The dev board was never the product. It was the fastest way to find out what the product should be, and it did that job well. The custom board is where the product becomes real — where it fits its enclosure, lasts on its battery, passes its tests, and can be made in the thousands. The decision to switch is not a technical milestone; it is the moment the project stops being an experiment and starts being a business.

Make it with the numbers written down, the requirements frozen, and the design reviewed, and it will be the least dramatic — and most valuable — decision in the project.

The dev board remains useful long after the switch, as a reference and a baseline. Keeping one on the bench is a small habit that makes every future hardware problem easier to diagnose, because it gives you a known-good comparison that is never in doubt.

A final framing for the switch: the dev board answers the question "can this work?" The custom board answers the question "can this be sold?" They are different questions, and the switch happens when the second one becomes the one that matters.

And finally: when the switch is made, make it deliberately. Freeze the requirements, review the design, and plan for one revision. Do those three things and the custom board becomes the moment the product gets real — not the moment the schedule gets risky.

Where we fit

We design and lay out custom ESP32 boards for teams making exactly this transition, from a working dev-board prototype to a manufacturable product: pcb-design for the full path from schematic to Gerbers, pcb-layout if you already have the schematic. Manufacturing and assembly run through PCB PCBA order online.

Tell us where your project is, and we will tell you honestly whether it is time to switch.

A dev board is a development tool; a product needs a board designed for it. Switch when the enclosure is defined, battery life matters, you are going to production, you need specific interfaces, cost matters at volume, or you need certification. A custom PCB gives you size, the exact interfaces, optimized power, manufacturability, and a certification path — at the cost of design, prototyping, iteration, and time.

Avoid switching too early (before requirements are stable) and too late (when you are trying to ship dev boards). Never skip debug access on a custom board.