ESP32 for Production: What Changes at 10000 Units

Your prototype works. It’s survived weeks of testing on your bench, impressed stakeholders in demos, and proven the concept is viable. Now someone’s asking when you can ship 10,000 units, and you’re realizing that the ESP32 DevKit you’ve been building on costs $8, weighs twice what your enclosure allows, and has no way to receive firmware updates once it leaves your facility.

The gap between “prototype works” and “10,000 units ship reliably” is where most ESP32 projects die. Not because the technology fails, but because teams discover at scale what they should have designed for from day one. A 0.1% failure rate sounds acceptable until you’re fielding 10 support tickets per week, each requiring a truck roll or RMA.

This isn’t about fear. It’s about deliberate redesign. Everything that follows addresses the specific hardware, manufacturing, and infrastructure decisions that separate successful production runs from expensive lessons.

Module vs. Bare Chip: The Decision That Shapes Everything Else

Before touching your schematic, answer this: pre-certified module or bare ESP32 chip?

This choice cascades through your entire project. A pre-certified module like the ESP32-WROOM-32E costs roughly $3-4 in volume and comes with FCC, CE, and IC certifications already complete. The bare ESP32 chip costs around $2 less, but that savings evaporates the moment you consider what you’re taking on.

RF certification alone runs $30,000-50,000+ for a new design. You’ll need RF engineering expertise to design the matching network, antenna, and shielding. The timeline extends by 3-6 months. And if you fail certification, you redesign and test again.

At 10,000 units, you’re saving $20,000 on silicon while risking $50,000+ in certification costs and months of delay. The math only works at volumes above 50,000-100,000 units, and only if you have RF expertise in-house.

The recommendation is straightforward: unless you’re building for extreme cost pressure at very high volumes, use pre-certified modules for your first production run. You can always move to bare chips in a future revision once you’ve validated market demand.

Hardware Changes That Can’t Wait

Your DevKit is a development tool, not a product. Here’s what needs to change:

Power System Redesign

Dev boards use linear regulators that waste power as heat and can’t handle the ESP32’s current transients during WiFi transmission. Production designs need switching regulators with proper input filtering, bulk capacitance for 300mA+ transmit bursts, and careful attention to brownout thresholds. The default brownout detector triggers at 2.43V. If your power supply dips below this during transmit, your device resets randomly in the field.

Sleep current matters too. A DevKit might draw 10mA in “sleep” mode. A production design should hit 10μA or less in deep sleep. That’s the difference between a battery lasting weeks versus months.

Antenna Considerations

The DevKit’s onboard antenna is tuned for an open-air test environment, not your plastic enclosure with a battery next to it. Production designs require antenna matching specific to your enclosure geometry and nearby components. This often means working with your CM or an RF consultant to tune matching components after you have production enclosures in hand.

If you’re using an external antenna, the connector and cable routing become critical. Every connector adds loss and a potential failure point.

Protection Circuits

Your DevKit includes ESD protection, reverse polarity diodes, and overcurrent limiting. Your custom board won’t have these unless you add them. At 10,000 units, you will encounter:

• Static discharge during handling and installation
• Users connecting power backwards
• Short circuits from installation mistakes
• Voltage spikes from inductive loads switching nearby

Design for these realities or budget for field failures.

Crystal Selection

The $0.15 crystal that worked fine on your bench may have ±50ppm tolerance and poor temperature stability. At volume, you’ll see units that won’t connect reliably, exhibit timing drift, or fail entirely at temperature extremes. Specify crystals with ±10ppm tolerance and verify temperature ratings match your operating environment.

Thermal Management

The ESP32 dissipates 0.5-1W under sustained WiFi activity. In a sealed enclosure, junction temperatures can exceed ratings within minutes. Your production enclosure design needs thermal analysis, whether that’s venting, thermal pads to the enclosure, or derated operation expectations documented clearly.

Design for Manufacturing: What Your CM Needs From You

Component selection and PCB design decisions made now determine your yield rates at scale.

Component sourcing: Check distributor stock and lead times for every BOM line item before finalizing your design. A single component with 26-week lead time holds up your entire production run. For every critical component, identify an alternate part and verify footprint compatibility.

PCB design rules: Your CM will provide design rules. Follow them exactly. This includes:

• Fiducial markers for automated pick-and-place
• Test points accessible by bed-of-nails fixtures
• Component spacing that allows rework
• Panelization designed for their equipment

Assembly pitfalls: Fine-pitch components (0.4mm and below) require specific pad designs to prevent bridging. QFN packages need proper thermal pad venting. Tall components shouldn’t shadow shorter ones during reflow. Tombstoning happens when pad sizes or thermal mass differ between ends of passive components.

Have this conversation with your contract manufacturer before finalizing design files. A 30-minute design review catches issues that cost $10,000+ to fix after boards are fabricated.

Design for Test: Building Quality In

Test strategy isn’t an afterthought. It’s a design requirement.

Every ESP32 leaving your line needs functional verification: Does WiFi connect? Do GPIOs toggle correctly? Does the power system regulate properly? Does the device communicate with your cloud backend?

This requires test points. Accessible, properly spaced pads that a pogo pin fixture can contact reliably for thousands of cycles. Plan for:

• Power rails (input, regulated outputs)
• Key GPIO signals
• Serial programming interface (always needed for initial firmware)
• Any analog signals requiring calibration

At 10,000 units, you need a programming and provisioning jig. Each device needs unique credentials: serial numbers, device certificates for TLS, provisioning tokens for your backend. This jig programs firmware, writes credentials to NVS, runs functional tests, and logs results, all in under 60 seconds per unit if you’ve designed for it.

Manual testing doesn’t scale. A 2-minute manual test across 10,000 units is 333 person-hours. Automate everything you can.

OTA Updates: The Feature That Transforms Post-Deployment Reality

If you implement nothing else from this article, implement over-the-air firmware updates before your first production run.

A device without OTA is frozen at ship date. Every bug becomes a recall or RMA. Every security vulnerability stays open forever. Every feature request requires new hardware to reach customers.

A device with OTA can improve indefinitely. Bug discovered in month three? Push a fix overnight. Security patch needed? Deploy to the entire fleet in hours. Customer wants a new feature? Ship it without shipping hardware.

The ESP32’s native OTA capabilities are mature. The standard approach uses A/B partitioning: two application partitions where one runs while the other receives updates. If an update fails, the device rolls back automatically to the known-good partition.

But OTA isn’t just firmware code. It’s infrastructure:

Your production design needs flash capacity for two application images plus an NVS partition for configuration and credentials. Plan your partition table now; changing it post-deployment is painful.

You need update servers capable of serving firmware images to thousands of devices, version management to track what’s deployed where, and monitoring to verify updates succeeded.

Security is non-negotiable. Sign your firmware images so devices reject tampered binaries. Use encrypted transport (TLS) so credentials aren’t exposed in transit. Implement rollback protection so attackers can’t downgrade to vulnerable versions.

Handle failure gracefully. Devices will lose power mid-update, encounter network timeouts, and run out of battery at inconvenient moments. Your update mechanism must survive all of these.

A field firmware update costs you server bandwidth. A truck roll to manually update a device costs $100-500. A full RMA with shipping, repair, and reshipping costs $50-150 per unit plus customer goodwill. OTA pays for itself on the first bug fix.

Certification and Supply Chain Realities

Pre-certified modules simplify regulatory compliance but don’t eliminate it. Your complete product (module plus your PCB plus your enclosure) still requires unintentional radiator testing. You’re certifying that your design doesn’t create spurious emissions through poor layout or inadequate filtering.

Budget 8-12 weeks and $15,000-25,000 minimum for FCC/CE certification of a complete product using pre-certified modules. Double those numbers if you’re designing with bare chips.

For supply chain, the 2021-2022 chip shortage taught painful lessons about ESP32 availability. Modules that were abundant became unobtainable for months.

At 10,000 units:

• Order components 4-6 months before production
• Use authorized distributors, not brokers (counterfeit components at scale are catastrophic)
• Second-source every critical component
• Maintain buffer stock for post-production repairs

What To Build Into Your Requirements Document Today

Production readiness isn’t a phase you enter. It’s a set of decisions you make during design. The path forward:

1. Commit to modules for your first production run unless volumes clearly justify bare chips
2. Redesign power, protection, and thermal systems for production realities
3. Engage your CM early on DFM and DFT requirements
4. Implement OTA infrastructure before finalizing your first production firmware
5. Build certification timeline and budget into your project plan
6. Secure component supply months before you need it

Thousands of ESP32-based products have made this transition successfully. The difference between them and the ones that failed isn’t luck. It’s recognizing that production is a different engineering discipline than prototyping, and treating it accordingly.

Hubble Network’s satellite-connected modules handle the RF certification and supply chain complexity that makes scaling IoT hardware painful. See the specs →