AI is the latest chapter in that story, and it follows an older pattern. Every previous generation of tools also produced the same failure mode: the belief that access to a tool is equivalent to the judgment required to use it well. Right now that pattern is most visible in one specific decision, which is what to build a custom controller on.
Ask an AI assistant which processor to use for a connected controller and the answer is very often an ESP32 module, a Raspberry Pi, or an Arduino, with Raspberry Pi Pico, Teensy, M5Stack, Adafruit Feather, STM32 Nucleo, or Nordic development kits close behind. That is a reasonable answer. These platforms are inexpensive, well documented, and backed by large communities and open source libraries, and a capable product engineer can have a prototype working in days. Many companies put their own engineers on this work because they want to own and manage their controller platform, which is a sound instinct.
The question this article addresses is what happens between that working prototype and a product that has to pass certification, survive a contract manufacturer’s production line, and run in the field for ten years.
The short answer is that the processor is rarely the whole problem. The risk lives in everything around it: power design, input and output protection, boot and reset behavior, the firmware update and security strategy, antenna placement, electromagnetic compatibility, and production test. Those things can be hardened, and hardening an existing design is a legitimate path as long as the architecture underneath is sound enough to harden. The least expensive time to find out is before a prototype becomes the product. The second least expensive time is now.
Key Takeaways
- The processor is rarely the real risk: the risk lives in everything built around it — power design, I/O protection, boot behavior, firmware robustness, and the certification path.
- A pre-certified module’s radio approval does not certify your product: your finished design still needs its own emissions, immunity, and environmental testing.
- The cheapest time to catch an architecture problem is before the first PCB spin: the most expensive time is during certification testing, after a board has already been built around it.
- Hardening a prototype is rarely all-or-nothing: most of the requirements knowledge and firmware logic carries forward, and only the parts that need to change actually change.
Why These Platforms Are Such a Natural First Choice
AI assistants recommend these platforms for the same reason: they have the most public documentation, the most tutorials, and the most example code. An assistant draws on what is widely published, which is a different thing from what is right for a specific product in a specific market. It cannot see your ten-year lifecycle requirement, your target certifications, your contract manufacturer’s preferences, or the electrical environment your controller will actually live in.
None of this means the team made a poor decision. The prototype answered the question it was built to answer, which is whether the idea works. The next questions are different, and they are the ones experienced hardware and firmware engineers are trained to ask.
Issue One: AI-Assisted Development Without Architecture Judgment
The limitation is the boundary of what the tool can know. An AI assistant recommending a microcontroller cannot know the component availability history of similar parts during the last supply chain disruption, the thermal profile of your enclosure, or the regulatory pathway your product needs to survive. AI-generated firmware has a similar boundary. It demonstrates the happy path very well, while the behavior that matters in the field, such as what the controller does when power sags, a sensor cable shorts, or a Wi-Fi connection drops mid-update, is usually left unhandled.
The pattern worth watching is the AI-assisted proof of concept that becomes the product architecture. A cross-functional team builds a working prototype faster than anyone expected. The demo goes well. Leadership is impressed. The schedule gets built around the assumption that the hard part is done. Then an experienced hardware team looks at what was built and finds a component with no industrial temperature margin, a power architecture that works on the bench but will fail in the field, or a communication design that will not pass EMC testing.
None of those problems are unfixable at the prototype stage. They get very expensive after a PCB has been spun and a firmware architecture has been built around specific peripheral assumptions.
Issue Two: Where the Development-Board Demo and the Production Product Diverge
The ESP32 as the common case. The ESP32 family is capable, and plenty of successful products ship on it, so the issue is rarely the chip itself. The first gap is certification. Many ESP32 modules carry their own radio approvals, such as FCC and CE modular certifications, and that is genuinely useful. It does not mean your product is certified. The module’s approval covers the radio, under specific conditions for antenna type and placement. Your finished product still has to pass its own emissions and immunity testing, and your enclosure, cabling, power supply, and board layout all influence the result.
The second is power. Wi-Fi transmission creates sharp current bursts, and a supply that looks fine on the bench can brown out the processor in the field, especially with long cables, shared supplies, or the transients found in industrial and vehicle environments. Intermittent resets that no one can reproduce are very often a power design problem. Our lab can inject brownouts, noise, and power fluctuations to find these weaknesses before a customer does.
The third is inputs and outputs. ESP32 pins are 3.3 volt logic with limited protection, and an industrial controller typically needs isolation, surge and ESD protection, and proper transceivers for RS-485, CAN, or 24 volt field wiring. Boot behavior matters too. Some pins have special roles during startup, so an output that should stay off can briefly toggle during a reset, which is not a small matter if it drives a relay, a heater, or a motor. On the original ESP32, certain analog inputs also cannot be used while Wi-Fi is active, which tends to surface late in a design.
The fourth is firmware robustness. A production controller needs a watchdog strategy, defined safe states, and an over-the-air update process that survives a power loss mid-write and can roll back a bad image. Security features such as secure boot and flash encryption rely on one-time programmable settings in the chip, so they have to be planned into the manufacturing process before the first production unit ships.
Raspberry Pi, Compute Modules, and BeagleBone. Linux-based boards bring a full operating system, which is wonderful for development and a source of risk in a product. A Raspberry Pi booting from a consumer SD card can corrupt its file system when power is cut unexpectedly, and a general-purpose Linux system is not a hard real-time controller. Boot time, long-term software maintenance, and open source license obligations all need to be managed deliberately in a commercial product. Compute Modules address the form factor and storage questions, but they still require a carrier board designed to your product’s electrical and environmental standards, which is a real PCB design project in its own right.
Arduino and Raspberry Pi Pico. Arduino-class boards and the Pico family are excellent for getting hardware to respond. The shortfalls tend to appear in the libraries and the I/O. Each community library a prototype depends on becomes part of the product’s long-term risk, with uneven maintenance and quality behind it, and the boards’ pins are not designed to survive industrial wiring, surges, or static discharge. Arduino’s professional lines, such as Portenta and Opta, narrow some of that gap, but the questions about your product’s certification scope and lifecycle still need answers.
Teensy, Adafruit Feather, and SparkFun boards. These boards are favorites because they are small, fast, and friendly. They are also designed for makers and low-volume builds. Some come from a single small supplier, which creates supply continuity questions for a long production run, and many are built with hand assembly and breadboard headers in mind rather than automated manufacturing, vibration, or conformal coating.
M5Stack and other all-in-one modules. Integrated units with a display, enclosure, and connectors are the fastest route to a working demonstration. The enclosure, connectors, and ports were designed around the vendor’s general-purpose product, so they rarely fit your environment, mounting, sealing, or wiring needs, and the integrated radio and enclosure combination does not carry certification over to your product.
STM32 Nucleo and Discovery boards, and Nordic nRF52 and nRF53 development kits. These are the most production-minded of the group, and the chips themselves have strong long-term availability programs and professional toolchains. What does not carry over is the development board. The onboard debugger, the power circuitry, the headers, and the radio layout are all for development, so a production design needs its own power, clocking, reset, programming and test access, and, for wireless designs, its own antenna layout and radio approvals. Bluetooth products also need qualification listing, which teams often discover late.
Home automation firmware stacks such as ESPHome and Tasmota. These are remarkable tools for connecting devices quickly. In a commercial product, the questions become who maintains the stack, how updates and vulnerabilities are handled, and how the product meets security requirements that did not exist when the community project was written.
Issue Three: Delaying Expert Engineering Engagement Until the Architecture Is Already Set
Product teams that engage hardware and firmware engineers at the requirements stage get something no tool can provide: the full context of the program applied to the decisions that shape everything downstream. The processor selection gets evaluated against lifecycle, thermal, and firmware complexity requirements together. The connectivity approach gets pressure-tested against EMC and certification requirements before it has been implemented. Sometimes the answer is an ESP32 on a properly designed custom board. Sometimes it is a different part entirely. Either way, it is chosen on purpose.
Teams that arrive later, after a year of internal effort, are not in a bad position. They have real requirements knowledge, a working reference for the product’s behavior, and firmware logic that often has value. The goal of an early review at that stage is to separate what is worth keeping from what needs to change, before more money is committed to either. We’ve also written about what engineering leaders should ask before approving a larger electronics redesign, if that bigger decision is the one you’re actually facing.
How to Harden a Prototype Controller for Certification and Production
If the original platform remains the right choice, which it often does, the work typically moves the design from a development board or module-on-carrier to a custom PCB with proper power conditioning, input and output protection, and a layout that supports EMC performance. Firmware is reviewed and hardened for fault handling, watchdogs, safe states, update reliability, and security. Then comes pre-compliance testing in our own lab, including radiated emissions scanning, ESD, power transient and brownout testing, temperature cycling, and vibration, so that problems are found and corrected before paying for formal certification runs. DE supports certification paths including FCC, CE, UL, ETL, CSA, IEC 60601 for medical products, and MIL-STD-461 for military programs. Finally, the design is prepared for manufacturing with design for manufacturability review and production functional test, so what was proven in the lab can be built repeatably.
Keep the Platform, Adapt It, or Start Over
Ownership is part of how we work. You own what we design for you. There is no proprietary platform you are locked into and no dependency on us to keep your product running. That matters to companies who chose to build in-house precisely because they wanted to own and control their own solution.
What Judgment-Led Development Looks Like
Why DE Design Works
Since 2002, we have been the experienced engineering team that product companies bring in when the architecture decisions matter and the margin for error is low. Our senior US engineers bring decades of context from industrial, medical, military, and IoT programs, and we combine PCB hardware design, embedded firmware, and connected-device expertise under one roof, along with an in-house lab for pre-compliance testing.
We use current professional-level tools, including AI-assisted development environments, because they make our background referencing tasks faster and more reliable. Then we apply judgment to everything those tools produce, because that is what our clients are actually paying for: real world experience.
If you are planning a controller and want experienced eyes on the architecture before prototyping, or you already have a working prototype on an ESP32, Raspberry Pi, Arduino, or similar platform and want an honest assessment of what it will take to reach certification and production, that is a conversation worth having.
Frequently Asked Questions
How do I harden an ESP32-based controller for certification and production?
Start with an architecture review of the power supply, input and output protection, boot behavior, antenna and layout, firmware fault handling, update and security strategy, and the target certifications. Then move the design from a development board or module-on-carrier to a custom PCB built for your environment, harden the firmware, and run pre-compliance testing for emissions, immunity, ESD, power transients, and temperature before formal certification. Production test and design for manufacturability should be planned alongside, so the result can be built repeatably.
Is the ESP32 suitable for industrial or medical products?
It can be, in the right architecture. Many successful products use ESP32 chips and modules. Suitability depends on the surrounding design, including power conditioning, isolation and protection of field wiring, temperature margin, a firmware update and security approach, and your lifecycle and regulatory requirements. Medical products add requirements such as IEC 60601 electromagnetic compatibility testing and software lifecycle documentation, which should be planned from the start.
Does using a pre-certified ESP32 module mean my product is already certified?
No. A module’s FCC or CE radio approval covers the radio under specific conditions, such as antenna type and placement. Your finished product still needs its own emissions and immunity testing, and your enclosure, cabling, power supply, and layout all affect the results. A pre-certified module reduces certification effort but does not eliminate it.
Why does my ESP32 prototype work on the bench but fail in the field?
The most common causes are power supply weakness, electrical noise and transients, inadequate input and output protection, undefined behavior at power-up or reset, and firmware that does not handle faults such as dropped connections or interrupted updates. Development boards and bench power supplies hide these issues, and field environments expose them.
Can I take a development board prototype straight to production?
Usually not without changes. A prototype built on a development board generally needs a custom PCB, a reviewed power and protection design, hardened firmware, and compliance testing before it is ready for production. How much changes depends on how closely the prototype’s architecture matches your product’s real requirements, which is what an architecture review determines.
Why do off-the-shelf development boards often fail certification?
They are designed for ease of use, not for emissions, immunity, or environmental performance. Layout, grounding, power filtering, cabling, and the enclosure all affect results, and a development board was never laid out with your product’s enclosure, wiring, or power supply in mind. Pre-compliance testing during development finds these problems when they are inexpensive to fix.
What is the difference between a development board and a production-ready design?
A development board is built to get a first result quickly, with headers, debugging circuitry, and general-purpose protection. A production-ready design is built around your product’s environment and requirements, with appropriate power and protection circuitry, a manufacturable layout, defined test access, firmware that handles faults, and documentation to support certification and long-term production.
Is Raspberry Pi suitable for an industrial controller product?
It can work for some applications, particularly when a Compute Module is paired with a well-designed carrier board. Common concerns include storage corruption during unexpected power loss, limited real-time behavior, boot time, long-term availability planning, and open source license compliance. These need to be addressed deliberately in the design.
Can Arduino, Teensy, Adafruit Feather, or M5Stack boards be used in a commercial product?
They can serve as a starting point and a proof of concept, but the boards themselves are typically designed for makers and low-volume builds. Common issues include unprotected I/O, dependence on community libraries, single-source supply, hand-assembly-oriented construction, and enclosures or connectors not designed for your environment. Most commercial products carry the software logic forward and move to a custom board.
We prototyped on an STM32 or Nordic nRF development kit. What changes for production?
The chips are often a strong production choice, but the development board is not the product. Production needs its own power, clocking, reset, programming and test access, and for wireless designs its own antenna layout, radio approvals, and Bluetooth qualification where applicable.
Should we keep our existing prototype or start over when we bring in a design firm?
Often the right answer is somewhere in between. Your requirements knowledge, application logic, and much of your firmware may carry forward, while the hardware platform, protection circuitry, and parts of the firmware architecture are redesigned. An early assessment can show what is worth keeping and what is not, along with the cost and schedule of each path.
Who owns the design when DE Design Works designs or hardens our controller?
You do. You own what we design for you, so you are not locked into a proprietary platform or dependent on us to support your product.
What cybersecurity rules apply to Wi-Fi and Bluetooth products sold in the EU?
The Radio Equipment Directive’s cybersecurity requirements have applied since August 2025, commonly demonstrated through the EN 18031 standards. The Cyber Resilience Act added vulnerability reporting obligations beginning September 11, 2026, covering products already on the market, with broader requirements scheduled for late 2027. Because these rules continue to evolve, confirm the current requirements for your product and market with a compliance specialist.
How early should we involve an electronics design firm?
Before prototyping if possible, and before the architecture is set at the latest. The cost of an architecture review at the requirements stage is small compared with correcting a foundational decision after hardware has been built and firmware has been written around it. If you already have a prototype, an assessment now still costs far less than discovering the same issues during certification testing.
Can AI tools design a production-ready controller?
AI tools are valuable for research, datasheet summaries, code scaffolding, and accelerating well-defined tasks. They cannot see your lifecycle, regulatory, supply chain, and environmental requirements, so their output needs to be reviewed by engineers with production and certification experience before it becomes your architecture.