The prototype is a question
A breadboard prototype answers one important question: can the idea work at all? It proves the sensor can capture a useful signal, the firmware can move it, and the software can make sense of it. That is real progress—but it is not yet evidence that the system will work where it matters.
The field introduces a different class of questions. How does the signal drift with temperature? What happens when the network disappears for six hours? Can a technician understand the device state without a laptop? Does the power budget still hold after retries, cold starts, and aging batteries? Reliability emerges from these edges.
Budget power before features
For a constrained device, energy is an architectural budget. Sampling frequency, local processing, radio choice, retry behavior, and update strategy all spend from the same account. The cheapest byte to transmit is often the one that can be reduced or classified locally.
I prefer to sketch the power model early—even when the numbers are rough. It forces useful tradeoffs into the open. A model that runs at the edge may cost compute but save radio time. A higher-resolution sensor may improve inference while shortening service intervals. The right answer belongs to the whole system, not one component.
- Measure sleep current on the real board, not only the data sheet.
- Design offline behavior as a primary mode, not an exception.
- Give firmware updates a rollback path and an energy ceiling.
Data quality begins at the enclosure
It is tempting to treat enclosure, mounting, calibration, and signal processing as separate workstreams. In practice, they are one data-quality pipeline. A sensor placed near a heat source produces a software problem. A loose mounting point becomes an anomaly-detection problem. Water ingress becomes a very expensive observability problem.
This is where electronics and software become genuinely interesting together. The physical design should make the data more trustworthy, and the software should make physical degradation visible before it becomes failure.
Design for explanation
Every deployed node needs a small, legible story about its own state: what it sensed, what it kept, what it sent, and why it could not send the rest. That story may surface through a status light, a local diagnostic record, or a fleet view, but it should exist before the first field issue.
The standard is simple: a person who did not design the device should be able to distinguish a sensor fault, a power fault, and a connectivity fault without guessing. Good diagnostics turn hardware support from archaeology into engineering.
The satisfying part
Connected hardware is unforgiving in the best way. It asks software architecture, industrial design, physics, operations, and user experience to agree. When they do, a small object can become a dependable part of a much larger system.
That transition—from a promising signal on the bench to trustworthy telemetry in the world—is the part I keep returning to.