From PCB to Product: What It Really Takes to Build Hardware
A working board on your bench is the start of hardware, not the end of it. Here is the full path from requirement to production — and the decisions that decide whether a product ships.
The first time a board you designed powers up and blinks an LED, it feels like the hard part is over. It isn't. That blink proves the regulator works and the microcontroller boots. It says nothing about whether the product survives a power cut, holds its Wi-Fi link through a concrete wall, passes testing, or can be assembled a thousand times without a technician nursing every unit.
That gap — between "it works on my bench" and "it ships" — is what PCB design and product development is really about. This guide walks through the full path the way we run it at Incrix Automation, using our own boards as examples, and flags the decisions that quietly decide whether hardware makes it to market.
TL;DR
- Requirements first. Function, environment, power, connectivity and target cost are fixed before a single footprint is placed.
- The PCB is a system decision. Stack-up, antenna placement and power design shape everything downstream.
- Firmware is part of the hardware. Plan OTA, recovery and power-loss behaviour from day one.
- Bring-up is a discipline. Test in a fixed order, measure, and expect at least one revision.
- DFM makes it a product. A board that can't be built repeatably at cost is still a prototype.
The five stages of PCB design and product development
Every board we build moves through the same five stages. The order matters more than the speed.
It looks linear on paper. In practice, each stage pushes back on the one before it: firmware exposes a pin conflict, validation exposes a thermal problem, DFM exposes a part that can't be sourced. Good hardware teams expect that feedback and design for it.
Stage 1: The requirement is the real first draft
Most hardware projects that go wrong went wrong before anyone opened a CAD tool. A useful requirement answers, in writing:
- What does it do? The functions, and just as importantly, what it does not do.
- Where does it live? Indoors or outdoors, dust, heat, vibration, mains noise, enclosure size.
- How is it powered? Mains, battery, solar — and what happens when that power disappears mid-operation.
- How does it talk? Wi-Fi, Bluetooth LE, Thread, Zigbee, LoRa, cellular — or nothing at all.
- What does it cost? A target bill-of-materials cost changes every choice that follows.
In India, the environment question carries more weight than most datasheets assume. Patchy connectivity, unstable power and sharp cost sensitivity are the normal operating conditions for a lot of field hardware, not edge cases. A device that needs a perfect network and clean power is a device that will generate support calls.
Choosing the silicon
The chip follows from the requirement, not the other way round. Two parts we use heavily show why.
The ESP32-S3 is a dual-core Xtensa LX7 running at up to 240 MHz, with 2.4 GHz Wi-Fi, Bluetooth 5 (LE) and vector instructions that Espressif positions for neural-network and signal-processing workloads. That makes it a natural base for general-purpose controllers and on-device intelligence — it's the chip behind our Horizon Gen 1 entry board and the Twinedge Dev V2 relay controller.
The ESP32-C6 takes a different path: a RISC-V core at up to 160 MHz plus a low-power RISC-V core, 2.4 GHz Wi-Fi 6 (802.11ax), Bluetooth 5 (LE) and an IEEE 802.15.4 radio for Thread and Zigbee. That combination is why our Horizon Dev-2 C6 and the 30×25 mm Hexon Atom C6 are built on it — they target Matter-ready and mesh-networked devices.
Neither is "better". They answer different requirements.
Stage 2: Schematic and multi-layer PCB layout
The schematic captures intent; the layout decides whether that intent survives physics.
Schematic decisions that echo later
- Power tree. Input protection, regulation, and what the rails do during brown-outs. Unstable supply is where many field failures begin.
- Programming and debug access. USB-C, boot and reset buttons, and exposed test points cost little now and save days during bring-up. Our Horizon Gen 1 keeps USB-C for power and programming plus boot and reset buttons for exactly this reason.
- Isolation for real loads. When a board switches mains — as the Twinedge Dev V2 does with four integrated relays, an on-board mains supply and screw terminals — clearances and separation between the high-voltage and logic sides stop being optional.
Why multi-layer
For a compact wireless product, a multi-layer stack-up gives you continuous ground and power planes, shorter return paths and room to route cleanly. That matters most around the radio: antenna keep-out zones, matching networks and ground-plane integrity decide your real-world range far more than the chip's headline specs.
Small form factors make this sharper. Fitting a hub into 30×25 mm, as with the Hexon Atom C6, with castellated edge pins so it can be soldered into another product, leaves no room for sloppy routing.
For layout, fabrication and assembly acceptance, the industry leans on standards published by IPC. Designing to the relevant class from the start is far cheaper than discovering at the fab that your board doesn't meet it.
Stage 3: Firmware is part of the hardware
It is tempting to treat firmware as something that happens "after the board". In reality, firmware requirements should shape the board.
- Bare-metal or RTOS? Tight, single-purpose control loops can live happily on bare metal. Anything juggling radios, sensors, a UI and cloud sync usually benefits from an RTOS.
- OTA from day one. Over-the-air updates need flash partitioning, a rollback path and a secure update flow. Retrofitting OTA after units are in the field is painful — and sometimes impossible.
- Power-loss behaviour. What happens if power drops mid-write, mid-print or mid-irrigation cycle? Our AI 3D printer work in Incrix Labs treats power-cut auto-resume as a core feature, precisely because Indian power makes it a real scenario.
- Security basics. Chips like the ESP32-C6 offer secure boot and flash encryption. Enabling and provisioning them properly is a firmware and manufacturing decision, not a checkbox.
We go deeper on the firmware-to-cloud layer in where hardware meets software.
Stage 4: Prototype, bring-up and validation
This is where schedules slip, so it deserves structure.
Bring-up in a fixed order
- Visual and continuity checks before power is applied.
- Power first, current-limited: confirm every rail, then check for heat.
- Clocks and boot: can the MCU be programmed and does it start reliably?
- Peripheral by peripheral: GPIO, sensors, relays, storage, radio.
- Full-function firmware only after each block has been proven on its own.
Doing it in this order means that when something fails, you know which block failed.
Validation is more than "it works"
| What you test | Why it matters |
|---|---|
| Radio range and stability | Lab range is not field range; walls, metal enclosures and interference change everything |
| Power interruption and brown-out | Devices must recover cleanly, not corrupt their state |
| Thermal behaviour | Enclosures trap heat; relays and regulators warm up under load |
| Long-duration runs | Memory leaks and connection drops often appear only after hours or days |
| Update and recovery | An interrupted OTA must never brick a unit |
Expect at least one board revision. A second spin is not failure; it's what the prototype stage is for.
Stage 5: DFM and production
A prototype proves the design can work. Design for manufacturing proves it can be built — repeatedly, at yield and at cost. This is where we do DFM in-house, because it changes decisions all the way back to the schematic.
- Parts you can actually buyEvery component should have realistic availability and, where possible, an alternate. A single unobtainable part can stop a production run.
- Footprints and panelisationPad geometry, orientation and panel layout affect assembly yield long before anyone notices a defect.
- Test points and production testEvery unit needs a fast, repeatable pass/fail check — firmware flashing, rail checks and a radio sanity test.
- Certification awarenessWireless, mains-powered and medical-adjacent products typically need regulatory testing and compliance for the markets they sell into. Plan for it early; it influences layout, shielding and component choices.
What our own boards taught us
Our shipping boards each lean on a different part of this process. Horizon Gen 1 is about accessible prototyping. Twinedge Dev V2 is about switching real loads safely. Horizon Dev-2 C6 is about multi-protocol radios. Hexon Atom C6 is about fitting a hub into a footprint small enough to embed. Our NDA work — a Wi-Fi control board that retrofits legacy weighing scales, and a point-of-care Wi-Fi height-measurement device — adds the constraint of fitting around someone else's existing product and users.
The shared lesson: in PCB design and product development, hardware is won or lost on unglamorous decisions made early.
Hardware is a team sport
Building hardware well means holding the board, the firmware, the cloud and the user experience in one head — or at least in one team. That's why we build across software, hardware and design rather than handing each layer to a different vendor, and why so much of our R&D points towards intelligence that runs on the device itself.
If you have a product idea that needs a board, start with the requirement. Write it down, put a target cost on it, and then talk to people who will tell you honestly what it takes. To see how this fits the bigger picture of what we're building, read what we're actually building at Incrix — or tell us about your hardware project.