Direct answer: An ESP32 product needs a reproducible firmware build, a verified power and radio design, recoverable provisioning and updates, and a documented programming and test package. Prove those paths on the intended PCB and enclosure before authorizing a pilot build.
Who this guide is for: Product teams moving from a working development-board prototype to a custom device. This is a planning and verification guide, not a specification for a particular SYANKOR board. Radio features, supply limits, security options and certification requirements depend on the selected device and complete product.
Review reconnect behavior, antenna placement, supply transients, update recovery, memory use and energy consumption as separate engineering risks. A successful bench demonstration does not verify all of them.
The difference between an ESP32 demo and an ESP32 product is not the number of features. It is the quality of the system around those features.
For the firmware reliability layer, read how embedded firmware moves from prototype code to a product and what must be frozen before an ESP32 pilot build.
Choose the next step from the evidence you have
- Working Arduino sketch; build settings are difficult to reproduce
- Preserve the application framework and follow the Arduino-to-PlatformIO migration checklist. Acceptance: another engineer can build the same release and repeat the baseline tests.
- Required behavior or platform support exceeds the current framework
- Evaluate a scoped ESP-IDF migration against the exact chip, framework version and dependencies. Acceptance: a representative end-to-end path and its recovery behavior work on target hardware before wider migration.
- Custom PCB or pilot build is approaching
- Use the pilot-build freeze checklist. Acceptance: hardware revision, firmware, provisioning, programming and test instructions identify the same approved release.
For implementation support, see ESP32 development services. The checks below help define the work before requesting a scope.
1. Start with product requirements, not the development board
Before selecting a chip or module, define:
- required Wi-Fi/BLE functions;
- number and type of peripherals;
- USB requirements;
- display/camera/audio requirements;
- processing load;
- RAM/flash needs;
- target battery life;
- enclosure size;
- antenna location;
- operating environment;
- target production volume;
- security requirements;
- update strategy.
This helps decide whether you need an ESP32, ESP32-C3, ESP32-S3, another ESP family member, or a different architecture entirely.
A chip chosen because “we already have sample code” can become expensive if the product later needs more RAM, USB, lower power or different radio behavior.
2. Decide between a certified module and a bare SoC deliberately
Using an ESP module can simplify early product development because the module integrates important RF and memory design elements.
A bare SoC provides more layout flexibility and may reduce unit cost at sufficient volume, but it increases design responsibility around:
- flash/PSRAM;
- crystal;
- RF matching;
- antenna;
- PCB stack-up;
- impedance control;
- power integrity.
For many startups and lower-volume products, a module is a good first production choice because it reduces RF-development risk.
For space- or cost-constrained products, a bare-chip design may be justified—but it should be treated as an RF hardware project, not simply a smaller module replacement.
3. Design the power supply for radio current peaks
Wireless devices do not draw constant current.
During RF transmit activity, current can rise sharply. If the 3.3 V rail has too much impedance, the voltage may dip and cause resets, brownout events or unstable radio behavior.
Capture the supply waveform at the device during connection and transmit activity, then compare it with the limits for the selected chip or module. Retain the test conditions and reset diagnostics with the result.
Review:
- regulator peak-current capability;
- input-source capability;
- bulk capacitance near the ESP device;
- local decoupling;
- regulator stability requirements;
- trace width and via count;
- ground-return path;
- voltage drop through cables or connectors.
Espressif’s current ESP32-S3 hardware guide also emphasizes the power network, local decoupling and transient behavior during RF activity.
Do not size the regulator only from average current.
4. Treat reset and strapping pins as part of the system architecture
ESP devices use certain pins during boot.
Those pins may later serve normal GPIO functions, but external circuitry can affect startup.
Before assigning peripherals, review:
- boot-mode strapping pins;
- reset/enable circuitry;
- USB/UART programming path;
- external pull-ups/pull-downs;
- whether connected sensors or drivers force a level during reset.
A product that boots reliably with a debugger attached but fails after the debug cable is removed may have a strap or power issue rather than a firmware problem.
5. PCB layout directly affects RF performance
Wi-Fi and BLE are not ordinary digital signals.
For a bare-chip RF path, controlled impedance, short routing, matching structures and a continuous reference plane matter.
For modules with PCB antennas, the base board and enclosure still matter.
Avoid placing near the antenna:
- metal enclosure parts;
- batteries;
- displays with metal backs;
- high-speed clocks;
- USB/UART circuitry;
- switching inductors;
- large copper pours inside the antenna keep-out area.
If the antenna is integrated into a module, place the antenna end near the board edge and respect the manufacturer’s keep-out guidance.
The final enclosure can detune the antenna, so test the assembled product, not only the bare PCB.
6. Validate RF with the final mechanical design
A product can show a strong RSSI on the workbench and still perform poorly in a customer’s home.
Test:
- throughput;
- reconnect reliability;
- range;
- orientation sensitivity;
- performance with the enclosure closed;
- performance while the battery is installed;
- coexistence with USB, display or other noisy subsystems.
Do not rely only on a development-board result because development boards often have generous antenna clearance that the final product does not.
7. Build provisioning as a real user workflow
An IoT product needs a way to receive network credentials and product configuration.
Possible approaches include:
- BLE provisioning;
- SoftAP/web setup;
- QR-assisted flows;
- factory pre-provisioning;
- wired service configuration.
The technical mechanism is only half the problem.
Also define:
- what happens when credentials are wrong;
- how the user retries;
- how factory reset works;
- how ownership transfer works;
- how the device indicates setup state;
- whether credentials survive firmware updates;
- how provisioning is protected from unauthorized access.
Remove shared development credentials from the release. Choose controlled factory provisioning or a protected user-setup flow that fits the product, and define how credentials are replaced and erased.
8. Use a connection state machine instead of scattered reconnect code
Keep Wi-Fi, transport security, broker connectivity and application readiness distinguishable in logs. This makes a failed connection traceable to the stage that actually failed.
A practical state machine may include:
BOOT → UNPROVISIONED → CONNECTING → ONLINE → DEGRADED → RECONNECTING
The device should know which state it is in and what event causes a transition.
Avoid uncontrolled reconnect loops that:
- consume power;
- flood logs;
- overload the network;
- block local product functions.
Use timeouts and backoff. Keep local functionality available when cloud connectivity is temporarily unavailable if the product permits it.
9. MQTT or cloud communication needs failure handling
Sending one MQTT message in a demo is easy.
Production behavior includes:
- broker unavailable;
- DNS failure;
- expired credentials;
- TLS negotiation failure;
- packet loss;
- duplicate messages;
- offline data buffering;
- connection migration after backend changes.
Define which messages are critical, whether they need acknowledgment, how much offline data can be stored, and what happens when storage becomes full.
The cloud protocol should support the product’s failure modes, not just its happy path.
10. OTA design should begin before flash partitions are frozen
OTA is easiest when planned early.
The partition strategy needs enough space for:
- bootloader and metadata;
- current application;
- update application image;
- persistent storage;
- logs/coredumps if used;
- factory or recovery functions if required.
For an ESP-IDF application OTA design, reserve the required OTA data partition and application slots for the selected configuration. Download into an inactive application slot, validate the image, and define how the first boot confirms health or rolls back. Application rollback does not automatically undo persistent-data migrations; design and test that compatibility separately.
For a production design, also consider rollback after a bad image.
Ask: What happens if power is removed at every possible point during an update?
Then test it.
11. Firmware updates should include authenticity and security considerations
A connected product should not install arbitrary firmware.
Depending on the threat model, ESP32-class products can use mechanisms such as signed application images, Secure Boot and flash encryption.
Security features should be planned with manufacturing because enabling one-time security configuration can affect:
- factory programming;
- rework;
- debug access;
- key management;
- field repair.
Do not turn on security features at the end without understanding the production workflow.
12. Low power is a duty-cycle problem
Battery products often focus on deep-sleep current because it is easy to measure.
Real battery life depends on the entire cycle:
- wake-up frequency;
- sensor measurement time;
- Wi-Fi association time;
- data-transmission time;
- failed reconnect attempts;
- CPU processing;
- peripheral leakage;
- regulator quiescent current;
- sleep duration.
A device can have excellent sleep current but poor battery life because it wakes too often or spends too long reconnecting.
Measure current with realistic network conditions and calculate energy per operation.
13. Watch heap behavior in Wi-Fi, TLS and OTA workloads
Networking stacks and encrypted communication can create temporary memory demand.
Total free memory does not show the largest allocation the device can satisfy. Track the largest free block and allocation failures alongside minimum free heap, using the relevant memory capabilities for the workload.
Monitor:
- free heap;
- minimum-ever free heap;
- largest free block;
- task stack margin;
- allocation failures.
Stress-test repeated connections, TLS sessions, provisioning and OTA cycles.
A device that works for one day is not evidence that it will work for six months.
14. Separate persistent data from firmware assumptions
Store configuration with a version identifier.
When firmware changes, migrate old data deliberately.
Typical persistent data may include:
- Wi-Fi credentials;
- calibration values;
- device identity;
- user settings;
- cloud endpoints;
- manufacturing data.
Do not let a firmware update reinterpret old flash structures accidentally.
Factory calibration and user configuration may also deserve separate namespaces or storage policies.
15. Design a manufacturing mode
Production needs a faster way to test the device than using the customer UI.
A factory test mode can expose commands for:
- GPIO test;
- LED test;
- button test;
- sensor readout;
- current measurement state;
- Wi-Fi/BLE RF test;
- serial-number programming;
- calibration;
- firmware-version check.
These functions can be triggered through UART, USB, test pads or another controlled interface.
The objective is to turn product verification into a repeatable pass/fail sequence.
16. Link firmware releases to hardware revisions
An ESP32 product may go through multiple board revisions.
A firmware build should know which hardware versions it supports.
Possible strategies include:
- resistor-coded hardware IDs;
- EEPROM/flash manufacturing data;
- GPIO strap identification;
- explicit product SKU configuration.
At minimum, field diagnostics should report firmware and hardware revision together.
That prevents engineers from debugging a software issue against the wrong schematic.
17. Test repeated failure and recovery cycles
A good ESP32 production test plan includes more than features.
Exercise:
- repeated Wi-Fi disconnect/reconnect;
- router reboot;
- invalid credentials;
- cloud downtime;
- repeated sleep/wake;
- OTA interruption;
- failed OTA image;
- low supply voltage;
- repeated power cycling;
- factory reset;
- long runtime.
Measure resets, error counters, memory health and recovery time.
Connected products live through transitions, so test the transitions.
What should count as a release acceptance record?
Agree pass/fail criteria before testing. Use a record that another engineer can repeat; do not substitute a generic number of successful cycles for a product-specific reliability requirement.
- Identify the release: board revision, module, firmware commit or build ID, framework version, partition table and configuration version.
- Specify the condition: power source, enclosure, network setup, attached peripherals and the fault introduced.
- Record expected and observed behavior: device state, reset reason, recovery path, memory health and relevant logs or waveforms.
- Track the decision: pass, fail or untested; the responsible reviewer; an open issue for every unresolved result.
Example test definition: interrupt network access while the device is operating, restore it, and check the agreed offline behavior, bounded reconnection, data handling and diagnostics. Repeat under the conditions in the validation plan and attach the evidence. This is a proposed test method, not a claim of results from a SYANKOR customer project.
ESP32 product-readiness checklist
Use the chip vendor’s documentation as the baseline, then validate it on the finished enclosure and PCB. Espressif publishes current guidance for ESP32 PCB layout and recoverable OTA updates.
For the selected hardware and SDK version, verify these details against the ESP32-S3 schematic checklist, ESP-IDF OTA and rollback documentation and heap-memory allocation documentation. The S3 hardware guidance applies to S3 designs; use the matching guide for another family. An approved module does not by itself establish compliance of the finished product.
Final thought
ESP32 reduces the time required to build a connected prototype, but it does not remove product engineering.
A reliable device still needs good power design, RF layout, robust state management, recoverable OTA, secure manufacturing, power measurement and production testing.
The strongest ESP32 projects treat hardware, firmware, cloud behavior and manufacturing as one connected system from the beginning.