Hardware prototyping with off-the-shelf dev boards

By Marco Lopes · July 24, 2023 · Hardware & Gear

Hardware ideas become useful when they meet physical constraints. A sensor needs a stable supply. A wireless connection has to survive a closed enclosure. A button must make sense to someone who has never seen the schematic.

At Kordspace, we approach hardware as part of a wider product system: electronics, firmware, software, connectivity, and design. As a remote collaborative studio, we also need prototypes that teammates can reproduce, inspect, and debug without sharing a workbench.

Off-the-shelf development boards give us a practical starting point. They let us test the risky parts of an idea before investing in custom electronics. The goal is not to assemble the most impressive collection of modules. It is to answer the right questions with the least unnecessary complexity.

Start with the uncertainty, not the board

Before choosing hardware, we write down what the prototype needs to prove. “Build a connected environmental monitor” is a product direction, not a useful experiment. “Check whether the sensor responds quickly enough inside the proposed enclosure” is something we can test.

We usually separate uncertainties into three groups:

• Physical: sensing accuracy, actuator behavior, placement, heat, and power.
• Digital: firmware timing, connectivity, data handling, and updates.
• Human: installation, feedback, accessibility, and everyday interaction.

We then choose the smallest build that addresses the biggest uncertainty. If we need to validate an interaction, a wired prototype may be enough. If battery life is the central question, a USB-powered demo will hide the problem.

This keeps early progress tied to evidence rather than the number of features we can demonstrate.

Choose a board for the job

Development boards are not interchangeable. We shortlist them by compute requirements, interfaces, power behavior, software support, and availability, not just headline specifications.

For straightforward sensing and control, an Arduino-compatible board can offer a quick route through established libraries and examples. We still check the exact board: processor architecture, voltage levels, and library compatibility vary across the family.

ESP32-based boards are useful when we need wireless connectivity alongside microcontroller behavior. We check the specific variant for its radio capabilities, pin restrictions, memory, and debugging options.

The Raspberry Pi Pico and Pico W are worth considering for compact microcontroller projects; the Pico W adds wireless connectivity. A Raspberry Pi 4 or another Linux single-board computer fits a different class of problem: richer interfaces, cameras, local services, or workloads that benefit from an operating system.

Our deciding question is simple: do we need Linux, or do we need predictable control? Sometimes we need both, with separate boards handling each role.

Evaluate the whole ecosystem

A cheap board can become expensive in engineering time if documentation is incomplete or the required peripheral lacks a maintained driver.

Before committing, we check schematics, pinout documentation, debugging support, library licenses, and whether examples match the current SDK. We also confirm that replacement boards and modules are obtainable. Availability matters particularly when collaborators need matching kits in different locations.

We prefer a known configuration over an ambiguous shopping list. “ESP32 board” is not a reproducible specification. We record the manufacturer, model, revision where available, and supplier reference.

The same applies to sensor breakout boards. Two modules with the same sensor chip may differ in voltage regulation, pull-up resistors, connectors, or level shifting. Those differences can explain why a circuit works on one desk and fails on another.

Build a boring, dependable bench setup

Our first milestone is a stable bench prototype, not a polished enclosure. We start with the board, a dependable power source, and one peripheral. We run a minimal test before introducing networking or application logic.

A basic kit includes a multimeter, suitable USB cables, a breadboard for low-current experiments, and labeled jumper wires. A logic analyzer helps with digital buses; an oscilloscope becomes valuable when timing or power behavior is unclear.

We check voltage compatibility before connecting anything. A 5 V signal can damage an input that only tolerates 3.3 V. We also verify pin assignments, shared grounds where appropriate, and whether a breakout already includes pull-ups.

Motors, relays, and other substantial loads need suitable drivers and power arrangements. We do not power them directly from GPIO pins. For mains-connected experiments, we use appropriately rated, enclosed equipment and qualified expertise rather than improvised breadboard wiring.

Treat power as a feature

Power problems often disguise themselves as software bugs. A board may run a simple example perfectly, then reset when a radio transmits or an actuator starts.

We map the power path early: source, cable, regulator, board, and peripherals. We check voltage under load and look for peak demand, not just average consumption. If USB works but a battery supply does not, we investigate the difference rather than adding arbitrary delays.

For battery-powered concepts, we measure the assembled system. Development-board LEDs, USB interfaces, regulators, and sensors can consume power even when the processor sleeps. A chip datasheet alone cannot predict prototype battery life.

We also distinguish exploration from estimation. A dev board can validate a sleep-and-wake strategy, but it may not represent a production design’s final consumption. We record what the measurement includes so nobody mistakes a bench result for a finished product specification.

Keep firmware understandable and recoverable

Prototype firmware should be easy to change without becoming disposable chaos. We separate hardware access from application behavior so we can replace a sensor or board without rewriting everything.

Our early firmware usually includes clear serial logs, explicit initialization failures, and a visible status indication. We avoid making “nothing happened” the only available diagnostic.

We pin toolchain and dependency versions, commit configuration examples, and document flashing and recovery procedures. Credentials stay outside the repository. Where practical, we run basic checks in continuous integration, even if physical-device tests still happen on a workbench.

We also design for failure early. Network operations need timeouts. Reconnection needs backoff. Watchdogs can help recover a stalled device, but they should not conceal a repeatable defect. We preserve enough diagnostic information to understand why a restart happened.

Connect to the cloud deliberately

We prefer Google Cloud when it fits the project, while also working with AWS and Azure. That preference does not mean every prototype needs a cloud connection from day one. Local serial output or a small local service is often enough to validate the hardware first.

When remote connectivity becomes useful, we define the data contract before building dashboards: device identity, measurement units, timestamps, schema version, and error states. We keep device time and server receipt time distinct, especially when clocks may be unreliable.

There is an important planning constraint as of July 24, 2023: Google Cloud IoT Core is scheduled to retire on August 16, 2023. We would not build a new prototype around it. Instead, we can evaluate a supported MQTT broker or partner platform, or an authenticated HTTPS ingestion service that forwards validated data into Google Cloud services such as Pub/Sub.

AWS IoT Core and Azure IoT Hub are alternatives when their device-management capabilities suit the project. Whatever the platform, we plan for duplicate messages, interrupted connections, bounded offline buffering, and per-device credentials. We never embed broad cloud administrator credentials in firmware.

Make remote hardware work reproducible

Remote collaboration changes what counts as documentation. A photograph of a working prototype is helpful, but it does not explain which wire is hidden behind the board.

We maintain a small hardware package alongside the code: a bill of materials, wiring table, annotated photographs, assembly notes, and a known-good firmware version. We label connections at both ends when the setup becomes more complex.

Each handoff includes a repeatable test: what to connect, what command to run, what output to expect, and what failure looks like. Short recordings are useful for interactions that logs cannot capture, such as a delayed indicator or an awkward button sequence.

For shared remote benches, we define who controls the equipment and how it can be reset safely. Remote access is useful; an unattended actuator with unclear ownership is not.

Test beyond the happy path

A prototype that works once has demonstrated possibility, not reliability. We build a small test matrix around likely real-world conditions.

We disconnect the network during transmission. We restart the access point. We remove and restore device power. We check what happens when a sensor is absent, returns invalid data, or stops responding.

We also test the physical arrangement. Wireless behavior can change when electronics move into an enclosure. Cable length can expose bus problems. Heat from nearby components can distort a temperature reading.

For each test, we write down the expected behavior and preserve useful logs. If the device should recover automatically, we verify that recovery rather than merely checking that it did not crash.

These experiments do not replace formal safety, compliance, or environmental testing. They help us discover obvious weaknesses before those later stages become expensive.

Know when to move toward custom hardware

Off-the-shelf boards are excellent learning tools, but they come with compromises: unused components, bulky connectors, uncertain long-term availability, and power overhead. Their dimensions may also force an enclosure into the wrong shape.

We consider a custom carrier board when wiring becomes fragile or connector placement matters. That intermediate step can improve repeatability while retaining a familiar compute module or development board.

A fully custom PCB makes more sense once the requirements and critical components have stabilized. Before that transition, we review programming access, test points, power protection, manufacturing constraints, and component sourcing.

We also revisit compliance assumptions. Using a radio module with existing approvals may simplify parts of the process, but it does not automatically certify the finished product. Antenna choices, enclosure design, and intended markets still matter.

The prototype’s job is to reduce uncertainty, not to bypass production engineering.

A short checklist before the next build

Before ordering parts or sharing a prototype, we check:

• Have we defined the question this build must answer?
• Are board models, electrical limits, and peripheral interfaces documented?
• Have we tested peak power demand and realistic failure conditions?
• Can a teammate reproduce the wiring and firmware build?
• Are credentials restricted, protected, and replaceable?
• Do we have a clear criterion for the next design decision?

Off-the-shelf dev boards let us connect physical ideas with software quickly, but their real value comes from disciplined experiments. At Kordspace, we bring hardware, design, cloud software, AI, and Web3 capabilities together where they genuinely serve the product. If we can help turn an early concept into a testable prototype, start a project, or explore our related services pages to see how we can collaborate.