You built an Arduino prototype and it works. The honest answer to "can we just manufacture this?" is almost always no — not because your work was wrong, but because a development board is a proving tool, not a product platform. The path to a sellable product runs through a custom circuit board that keeps your logic, your sensor choices, and your calibration, while dropping everything the dev board carries for the benefit of hobbyists. This article explains exactly what changes, what survives, and the narrow cases where shipping a dev board really is the right call.

Why Arduino is a great prototyping tool

Start with the credit, because it matters: an Arduino-class board probably saved you months. A forgiving toolchain, a library for nearly every sensor, a huge community, and a board price in the tens of dollars make it the fastest way on earth to answer the only question that matters early on — is this physically possible? A working breadboard rig is also a legitimate investor demo and a real user-testing instrument. That is the job of a proof of concept, and yours did it.

The five gaps between a dev board and a product

  • Cost and size. Your Arduino is loaded with parts your product does not need: unused headers, a USB-to-serial bridge, indicator LEDs, a barrel jack, a voltage regulator sized for someone else's project. In manufacturing you pay for every one of those in dollars, in enclosure volume, and in current draw. A purpose-built board contains only what your product uses, and at production volume it typically costs a fraction of the dev board.
  • Reliability and interconnect. Jumper wires and headers survive a desk. They do not survive drop, vibration, thermal cycling, or a shipping container. A product needs one board with everything soldered down, sized and routed properly — see what low-volume boards actually cost in our guide to PCB prototype cost.
  • Power budget. Development boards were never designed for battery life. Real battery products need a deliberate power architecture: efficient regulators, rail sequencing, low-quiescent-current parts, and firmware sleep states. Dev boards leak current through circuitry you are not even using.
  • Certification. A commercial electronic product has to pass emissions and safety testing. A stack of boards and flying leads almost never passes, and more fundamentally you cannot certify an assembly of loose modules — certification applies to a defined product with a fixed circuit and fixed layout. See FCC certification for electronic products for how that process works.
  • Supply continuity. Production requires control of your own bill of materials: real part numbers, second sources, lifecycle data, and approved alternates. A third-party board gives you none of that, and if the vendor revises it, your product changes without your consent.

The good news: most of your work carries forward

Redesign does not mean starting over. The application logic you wrote, the sensors you proved out, the thresholds and filter constants you tuned experimentally, and your hard-won understanding of real use cases all transfer directly — and they are usually the expensive part of the knowledge, not the hardware.

Often you can even stay in the same silicon family. The microcontroller on your board almost always exists as a bare chip or module you can solder onto a custom design, so a large share of your firmware ports with modest changes to pin mapping and peripheral initialization. Choosing the final part is its own decision, covered in how to choose a microcontroller and ESP32 vs STM32. If your prototype leans on a single-board Linux computer instead of a microcontroller, the same logic applies with an extra wrinkle: boot media, operating system updates, and long-term board availability all become your problem.

What the transition project actually looks like

  1. Requirements freeze. Turn the prototype's behavior into a written spec: inputs, outputs, timing, power, environment, and the intended cost target.
  2. Architecture and part selection. Pick the MCU, radio, sensors, and power topology with availability and certification in mind.
  3. Schematic and layout. Design the board, then review it for manufacturability and for EMC before fabrication, not after a failed test.
  4. Firmware port and bring-up. Move your logic to the new hardware, add production features the prototype never had: watchdogs, brownout handling, diagnostics, and often field updates.
  5. Build stages and testing. Iterate through engineering, design, and production validation builds — the discipline explained in EVT, DVT, and PVT.

Expect this to be a real engineering project measured in months rather than weekends, with two or three board revisions as the normal case, not a sign of failure.

When shipping the dev board is genuinely fine

Not every product ends up on a retail shelf. A one-off factory machine, a production-line test fixture, an art installation, a research instrument built in single-digit quantities — in those cases an industrial-grade development board inside a proper enclosure can be a completely legitimate, cost-effective answer. The dividing lines are volume, regulatory exposure, and expected service life. Once you are talking about hundreds of units, sales to consumers, or a manufacturer's warranty, you move to a custom design.

Turn a working proof into a manufacturable product

A working Arduino prototype is a strong starting position: it proves the concept is alive and defines precisely what the product must do. Projects House takes US clients from that point forward — schematic and PCB design, firmware, enclosure, and production-intent prototyping under one roof. Send us your prototype description and target cost through the contact form and we will map out what it takes to make it manufacturable.