IoT Product Bring-Up Checklist: From PCB to First 100 Units

The first 100 units of a new IoT product are where ten months of hardware design get tested by reality. A disciplined bring-up sequence catches issues at the cheap stage; an undisciplined one catches them at the expensive stage. Here is the checklist we run on every project.

Phase 1 — Bare board (before any firmware)

Visual inspection

• Solder bridges, missing components, wrong-orientation parts, BGA reflow quality
• Compare against the BOM and the assembly drawing
• Photograph both sides for record

Power

• Apply power through a current-limited bench supply (set the limit ~50% above expected)
• Probe each rail with an oscilloscope, not just a meter — looking for ripple and stability
• Measure quiescent current — anomalously high current means a short or a misplaced part

Clocks and resets

• Crystal oscillator running at expected frequency (probe the GPIO XO output if available)
• Reset signal clean and not floating
• Optional: confirm 32 kHz LFXO if the design uses it

This phase is 30 minutes per board. It catches roughly 60% of all hardware bugs at the cheapest possible point.

Phase 2 — MCU programming and console

Toolchain

• Connect via SWD/JTAG/UART
• Successfully program a known-working bootloader or first firmware image
• Establish a serial console on whatever debug UART exists

GPIOs

• Toggle each LED to confirm output direction
• Read each button to confirm input direction
• Probe each unused GPIO for unexpected drive (catches schematic errors)

This is where firmware engineers can start working in parallel with the hardware team. Get this phase done in week 2 of bring-up.

Phase 3 — Peripherals

For each peripheral, in roughly this order:

I²C / SPI sensors

• Detect device on bus (read the WHO_AM_I or device-ID register)
• Read a known-good value
• Write a value and read it back
• Run for an hour at 25°C; check for hangs

ADC

• Apply known voltages to each input
• Verify reading matches expected within tolerance
• Check noise floor with the input grounded

External flash / EEPROM

• Read JEDEC ID
• Erase a sector, write a pattern, read back
• Verify endurance counter (if the part supports it)

USB / Ethernet (if equipped)

• Enumerate against a host PC
• Run a sustained throughput test
• Power-cycle 100 times to check enumeration reliability

Display / Camera (if equipped)

• Initialise per the datasheet
• Display a known test pattern
• Pixel-perfect verification — usually catches a mis-routed signal that a casual visual inspection misses

The peripherals phase is the longest. Budget 2–4 weeks for a typical IoT product depending on the peripheral count.

Phase 4 — Radio bring-up

RF performance

• Conducted measurement on a spectrum analyser (TX power vs. spec, harmonics, spurs)
• Receiver sensitivity (modulated signal generator into the antenna port)
• Frequency stability across the operating temperature range

Protocol stack

• BLE: advertise, connect from a phone, exchange data, disconnect cleanly
• Wi-Fi: associate, IP via DHCP, ping, sustained throughput
• LoRaWAN: join, send uplinks, receive downlinks, ADR working
• Cellular: register on network, attach to APN, send/receive data

Antenna validation

• Compare actual radiated performance with simulation
• Walk-around with a phone or signal generator if antenna is internal
• Confirm placement of the antenna doesn’t change radiation pattern badly when assembled with the rest of the enclosure

Radio bring-up is where late surprises happen. Do it on the first PCB revision; do not defer to the production design. See our cellular modules post for module-side specifics.

Phase 5 — Power profiling

Run the device through every operational state with current measurement:

• Deep sleep (lowest current state)
• Idle (waiting for an event)
• Active sensor read
• Active radio TX
• Active radio RX
• Boot
• OTA update

Compare each measurement against the power model spreadsheet (our BLE battery post walks through the math). Discrepancies of more than 20% indicate either a model bug or a hardware issue. Find the root cause; do not paper over it.

Phase 6 — Pre-compliance EMC

Before paying for full certification, run a pre-scan:

• Conducted emissions on the power lines
• Radiated emissions in a screened room (or open-area test site)
• Identify peaks above the limit line
• Iterate on PCB and enclosure changes to reduce emissions

A failed pre-scan is much cheaper than a failed full FCC/CE certification test. Budget for it; do not skip it.

Phase 7 — Factory test

Build the test fixture and software for production:

• Programs the firmware
• Writes per-device credentials and certificates
• Runs a functional test sequence (LED, button, sensors, radio)
• Logs the result to a manufacturing database
• Prints a label or marks a flag for pass/fail

The fixture is infrastructure, not an afterthought. Without it, every unit needs an engineer to bring up. With it, the contract manufacturer can run a production line.

Phase 8 — First 100 units

The first 100 units are diagnostic instruments, not products:

• Capture per-unit telemetry from day one of customer deployment
• Track every RMA (return merchandise authorisation) with detailed teardown
• Look for patterns — “every device built on Tuesday has higher failure rate” type insights
• Iterate the design and process before scaling

This phase is where the BOM, the firmware, and the manufacturing process meet customer reality. Most products have surprises here. Plan the iteration cycle.

What we hand over

For every IoT product engagement we ship:

• A bring-up runbook (this checklist, customised for the specific product)
• Per-phase pass/fail criteria
• A factory test fixture specification
• A first-100-units feedback loop
• The signed-off DFM/DFT review with the contract manufacturer

The runbook is the operational asset that makes the second product easier than the first. If you are about to bring up your first IoT board — or if your second one is feeling as hard as the first — we run bring-up support as fixed-scope engagements.