From prototype to industrial production: the 12-step checklist

"The prototype already works. Now what?"

It's the question I've been asked most often since we founded Industrial Shields in 2012. And the answer is never "install it": between the lab bench and the plant floor there's a process, and skipping steps always costs you — usually in the middle of the night, with the machine down and the client on the phone.

The good news is that this process isn't a mystery. After watching hundreds of integrators and OEMs walk the road from prototype to industrial production, the steps that separate the ones who arrive smoothly from the ones who arrive in fits and starts are always the same. We've distilled them into this 12-step checklist, organized into 4 phases: harden the hardware, toughen the software, document and certify, and install and maintain.

This is the full, expanded version. Use it as a working document: print it, hand it to your team, and don't consider a phase closed until its steps are checked off.

Why "it works" doesn't mean "it's ready"

Before the list, the idea it rests on: the lab bench is the friendliest environment your system will ever know. Stable temperature, clean power, zero vibration, two-meter cable runs, and you standing right there to reset whatever needs it.

The plant floor is the opposite in every way: 45-50 °C inside the cabinet in summer, transients on the 24 V line every time a motor starts, drives emitting electromagnetic noise, continuous vibration, and nobody standing there. Industrializing an Arduino, ESP32 or Raspberry Pi prototype isn't about putting it in a box: it's about closing, one by one, every gap between those two worlds. That's exactly what these 12 steps do.

Phase 1 — Harden the hardware (steps 1-4)

Step 1. Inventory the weak points

List every component in the prototype and ask it three questions: does it withstand the cabinet's temperature range? does it withstand vibration? what happens if it fails?

The usual suspects: DHT11/DHT22-type sensors, Dupont jumpers and breadboards, unbranded relay modules, power supplies with no real certification, and consumer microSD cards. Each one has an industrial equivalent (Pt100 with 4-20 mA transmitter, terminal blocks with crimped ferrules, relays from a recognized manufacturer, DIN-rail power supply, pSLC card). The output of this step is a table: component → risk → replacement → cost. That table is, in fact, the first draft of your industrial bill of materials.

Step 2. Migrate to protected I/O

Everything that goes in or out of the controller becomes optocoupled, protected against transients, and wired into real terminal blocks with a defined torque spec.

This is the step where a prototype built on Arduino, ESP32 or Raspberry Pi migrates naturally to its industrial PLC version without rewriting the code: same architecture, same programming environment, same libraries. The difference is that every digital input now runs through an optocoupler (a field fault burns out that channel at most, not the CPU), every output is sized for real loads, and every communication port carries its own protections. It's the shortest and cheapest path in the whole process: you keep your software investment and change only the layer that had to change.

Step 3. Power supply with hierarchy

The prototype's power supply is usually "one supply for everything." On the plant floor, that's a scheduled failure. The correct structure:

• Industrial DIN-rail power supply from a recognized manufacturer, sized with margin for inrush current, not average consumption.
• Upstream protections: circuit breaker, surge protection where the environment calls for it.
• Separation between electronics and actuators: the PLC's CPU and the solenoid valves that draw current spikes don't happily share the same supply. Separate supplies or, at minimum, sizing and filtering that guarantees a field consumption spike doesn't turn into a micro-dropout on the CPU.

Step 4. Stress testing, not functional testing

The prototype already works; now you have to try to break it. The minimum plan:

• Power cycling: dozens of outages at the worst moments of the machine cycle.
• Sustained high temperature: 48 hours at real cabinet temperature (not office temperature).
• Hot-swapping sensors: what does the system do when the 4-20 mA signal disappears?
• Noisy bus: communications running while inductive loads switch nearby.

Every failure caught here costs 10 times less than the same failure on the plant floor. Document every test: date, condition, result. You'll thank yourself at step 9.

Phase 2 — Toughen the software (steps 5-8)

Step 5. Mandatory watchdog

A hardware watchdog, always armed: if the program hangs, the device resets itself and the machine lands in a safe state. "It hung and someone had to go reset it" is not an acceptable incident on the plant floor. And watch out for the classic silent failure: the watchdog that got disabled "for debugging" and never got turned back on. Arming it should be part of the program's startup, not a manual step.

Step 6. Safe state defined by design

On loss of communication, power, or a sensor: what does each output do? Decide this on paper, output by output, with justification, before writing the code that implements it. If the answer to "what does the pump do if it loses the level sensor?" starts with "I guess...", there is no safe state: there's just luck. This document is also, incidentally, a piece of the risk analysis that CE marking will ask for (step 10).

Step 7. Communications with retry and diagnostics

The bus will fail at some point; the difference between an industrial system and a prototype is whether the program logs it and recovers, or sits there waiting forever. The minimum: timeouts on every transaction, retries with a limit, accessible error counters (so maintenance can see the bus is "running tight" before it goes down), and an explicit decision about what happens to the logic when a slave doesn't respond — which is exactly the safe state from step 6, applied to communications.

Step 8. Autonomous startup

The device has to come back into production on its own after a power outage, in the right order, with nobody there. That means: a defined startup sequence (what gets restored first, control or actuators?), persistent state where needed (counters, setpoints), and zero manual intervention. Test it by actually cutting the power, repeatedly, at the worst moments of the cycle. If on the twentieth test it comes back on its own, it's starting to look like industrial equipment.

Phase 3 — Document and certify (steps 9-10)

This is the phase the newsletter email left open — and where the step almost everyone does too late lives.

Step 9. Technical file from day one

This is that step. The technical file — the folder that proves your assembly complies with the directives that apply to it — can be built two ways: while you build the equipment, or afterward, archaeologically, digging up paperwork for components you bought months ago. The second way is what delays (and derails) CE marking for most projects.

What to collect as you go:

• Declarations of conformity and documentation for every critical component (power supply, PLC, protection devices), requested from the supplier at the time of purchase. A component with no real documentation is a hole in your file — and discovering it at the end means going back to phase 1.
• Electrical schematics as actually built, not reconstructed from memory.
• The safe-states document (step 6) and the test records (step 4): these are direct evidence for the risk analysis.
• EMC design decisions: shielding, cable-tray separation, equipotential bonding.

Step 10. Conformity assessment and CE marking

With the file built, this step is documentation work, not redesign. For a typical control panel, the Low Voltage Directive (2014/35/EU) and the EMC Directive (2014/30/EU) apply; if you're delivering a complete machine, add the Machinery Directive (2006/42/EC) with its risk assessment, and the electrical part per EN 60204-1. In many cases the assessment can be done through self-certification with a solid file, with no external lab needed — the full detail on directives, standards and common mistakes is in our CE marking guide for integrators. The declaration of conformity is signed by whoever places the assembly on the market or puts it into service: you.

Note for readers outside Europe: CE marking applies to the European market. If you sell into North America, the equivalent framework is UL/CSA certification — see our companion CE marking guide for the certification detail.

Phase 4 — Install and maintain (steps 11-12)

Step 11. Pilot installation with an observation period

The first real installation isn't a delivery: it's a trial with intensive follow-up. The first 2-3 weeks on the plant floor turn up what no lab ever found — that customer's exact combination of temperature, noise and real-world use. Plan for it: remote access if possible, event logging turned on, scheduled visits, and an explicit commitment to the client that this period exists. Committing to serial production without going through this is betting your reputation on a coin flip.

Step 12. Monitoring and documented maintenance

And this is the only step that keeps working for you years after commissioning. It consists of leaving the system observable and maintainable:

• Telemetry and logging: bus error counters, internal temperature, restarts, running hours. What doesn't get measured breaks by surprise.
• Written maintenance plan: retorquing terminals after the first weeks of vibration, power-supply checks, a replacement cycle for wear items (relays, SD cards if any).
• Installation dossier: final schematics, software versions, parameters, Modbus map. Whoever handles the failure five years from now — who might not be you — will solve in an hour what without a dossier takes two days.

Every avoided failure, every remote diagnosis, and every extension quoted without a site visit comes out of this step. That's why it's the one still paying dividends when the project itself is barely a memory.

The complete checklist, at a glance

One reading rule: the steps aren't optional, but they are parallelizable. The technical file (9) gets built throughout phases 1 and 2; stress testing (4) overlaps well with software hardening (5-8). The only thing that doesn't work is skipping them: every omitted step comes back later, more expensive, and with an audience.

📥 Download the checklist: "From Arduino Prototype to Industrial Installation"
The 15-point checklist in a printable PDF — the expanded version of these 12 steps, with check boxes, "how to verify it" for each point, and the typical mistake to avoid — ready to use on your next project.
Download the free checklist →

Are you on step 2? The fastest way to migrate to protected I/O without rewriting code is to use an industrial PLC on the same platform as your prototype — Arduino, ESP32 or Raspberry Pi: https://www.industrialshields.com/shop. And if your product needs something the standard catalog doesn't cover, that's what our custom product design service is for (custom solutions): product definition, from idea to working prototype, and manufacturing with industrial-grade components — https://www.industrialshields.com/industrial-open-source-hardware-custom-solutions