Ship It Once, Reach It Never: Designing for Hardware You Cannot Touch

Mostafa Dhouib·September 7, 2026·7 min read

Ship It Once, Reach It Never: Designing for Hardware You Cannot Touch

The short answer. Once a unit ships, your remaining influence over it runs through whatever channels you built before it left. So the central design question is not what the product should do, it is which properties must be correct at manufacture and which can be changed later. Everything you can move from the first category to the second is risk removed from a decision made under the least information you will ever have.

Software has trained an entire generation of engineers on the assumption that mistakes are recoverable. Ship it, watch it, fix it.

Hardware in the field removes that, and it removes it across the whole production run simultaneously. Twenty thousand units with the same defect is not twenty thousand problems. It is one problem you cannot reach.

The three tiers

Every property of a shipped device falls into one of three tiers, and knowing which is the entire discipline.

Fixed at manufacture. The sensor, the analog front end, the compute module, the memory, the radio, the antenna, the enclosure, the power budget. Changing any of these is a hardware revision, which means new units rather than an update.

Changeable by update, if the update path holds. Application firmware, algorithms, thresholds, protocol handling, and the user-facing behaviour. This tier exists only because the update mechanism works, which makes the update mechanism the most load-bearing component in the product.

Changeable by configuration, without a firmware release. Tuning parameters, feature toggles, reporting intervals, backend endpoints. The cheapest tier, and consistently underused.

The design work is moving things down this list. Every property you can shift from tier one to tier two, or tier two to tier three, is a decision you get to make later, with more information than you have now.

What belongs in tier one, and the arithmetic that decides it

Some things genuinely cannot move, and the important ones are physical.

What the sensing can acquire is bounded when the sensing approach is chosen. Electrode type, bandwidth, noise floor, sampling rate, placement. No downstream processing recovers information that was never acquired, so a capability claimed above that ceiling cannot be rescued by a firmware update.

Memory bandwidth bounds inference latency. If your latency problem is bytes crossing the bus per inference, no amount of model optimisation reaches past what the part can move. That is a component decision, made early, binding on everything after.

Power determines what can run continuously, which determines duty cycle, which determines what the product can actually do rather than what it can demonstrate.

The check for all three is arithmetic available very early, and skipping it is how a program discovers at integration that its central claim was never physically available. Doing that arithmetic before the parts are chosen is the highest-return hour in the schedule.

What people leave in tier one by accident

More interesting, because these are avoidable.

Hard-coded endpoints. A backend URL compiled into firmware means a domain change becomes a fleet update, and a fleet update depends on reaching units through the backend you are trying to change. That is a circular dependency with a fleet on the other side of it.

Fixed certificate lifetimes with no rotation path. The device works for the certificate's life and then stops, on a date you can calculate. This is a scheduled outage you have already committed to.

Thresholds compiled in. Every constant tuned during development that turns out to be wrong in the field becomes a firmware release, and firmware releases have cost and risk that a configuration change does not.

Protocol assumptions with no negotiation. A device that speaks exactly one version of your protocol cannot be kept working across a backend evolution, which constrains the backend for the life of the fleet.

Each of these is nearly free to avoid at design time and expensive past manufacture, which is the definition of a decision worth making deliberately.

The recovery path comes before the capability

The ordering that feels wrong and is right.

Before the product does anything interesting, it needs: a reliable update mechanism with rollback that does not depend on the new image, the ability to report that it is alive, and a way to reach a known-good state from a bad one.

Build and harden those first. They are unglamorous, they demonstrate nothing, and they are what makes every subsequent decision reversible. A device with a solid update path can ship with known imperfections. A device without one has to be right at manufacture, which is a standard no test plan fully reaches.

The corollary for planning: if the schedule pressure is such that the recovery path gets deferred to make room for features, the program has chosen to make every feature decision irreversible in exchange for shipping them sooner.

Absence is the only honest fleet signal

A unit that has failed cannot tell you it has failed. So the health of a fleet cannot be measured by what arrives; it has to be measured against what should have arrived.

Expect a check-in. Every unit, on a known interval.

Track time since last contact per unit, not aggregate message volume. Volume stays healthy while a tail of units goes dark, because the healthy majority dominates the number.

Represent gaps rather than smoothing them. A chart that interpolates across missing data is asserting something nobody knows.

Alarm on sustained absence, not a single miss. One missed check-in is noise; ten consecutive is a state.

This is the same requirement as detecting a silent node on a server fleet, and it is missed for the same reason: monitoring systems are built to collect signals, and the signal that matters most is the one that stopped.

The questions to answer before tooling is committed

What is fixed at manufacture, written as a list? If nobody has written it, it is longer than anyone thinks.

What is the physical ceiling of the sensing, and where is the product claim relative to it?

What does the update path depend on, and is any of it also updatable? Circular dependencies here are common and fatal.

What can a unit do to recover itself with no human present?

How would we know that four hundred units have gone dark?

Programs in connected hardware and embedded that answer those five before tooling is committed spend their field life adjusting configuration. Programs that do not spend it planning firmware releases, and occasionally planning truck rolls.

FAQ

How should you design hardware you cannot physically reach? By sorting every property into three tiers: fixed at manufacture, changeable by firmware update, and changeable by configuration. The design work is moving as much as possible down that list, because each move converts a decision made now into one you can make later with better information.

What genuinely cannot be changed after manufacture? The physical bounds: what the sensing can acquire, the memory bandwidth that limits inference latency, and the power budget that determines duty cycle. All three are arithmetic you can do before selecting parts, and skipping that arithmetic is how a program discovers its central claim was never available.

What gets accidentally locked at manufacture? Hard-coded backend endpoints, certificates with no rotation path, thresholds compiled into firmware, and protocols with no version negotiation. Each is nearly free to avoid at design time and expensive afterwards, and the endpoint case creates a circular dependency where the update path runs through the thing you need to change.

Why build the recovery path before the features? Because it is what makes every later decision reversible. A device with a reliable update mechanism can ship with known imperfections; a device without one must be right at manufacture, which is a standard no test plan fully reaches.

How do you monitor a fleet you cannot reach? By expecting a check-in from every unit on a known interval and tracking time since last contact per unit rather than aggregate message volume. A failed unit sends nothing, so absence measured against expectation is the only honest signal.