Research prototypes for physiological sensing are often impressive. Lab conditions are controlled. Subjects are cooperative. Algorithms are tuned on clean data. Results are published and celebrated.
Production is different.
Building health sensing systems that work for real people, in real conditions, at scale, exposes a class of engineering problems that don’t appear in research settings. Here’s what I’ve learned.
The environment is the adversary
In a lab, the environment cooperates. Lighting is controlled. Motion is minimized. Subjects sit still. Skin properties are typical.
In the real world, everything is variable. Ambient light changes. People move constantly. Skin pigmentation varies widely. Placement is inconsistent. Temperature fluctuates. Artifacts come from unexpected sources.
The first lesson of production health sensing is that your algorithm needs to perform across this full distribution, not just at the center of it. And the distribution is wider than you think.
Most research algorithms are tuned on datasets that don’t reflect this distribution. They work well on the subjects they were trained on and fail in ways that are hard to predict on everyone else. Building robust algorithms requires data collection that deliberately captures edge cases — and then verification that your algorithm actually works on them.
Accuracy claims require context
Consumer health sensing products make accuracy claims that deserve careful reading.
Accuracy is not a single number. It’s a function of the population being measured, the conditions under which measurement occurs, and the metric being used to evaluate it. A claim of “98% accuracy” means something very different when measured on a homogeneous lab population under controlled conditions versus a diverse population in real-world conditions.
The regulatory environment for consumer health sensing is evolving. The standards for what must be disclosed and validated are getting stricter. This is good — it will push the industry toward more honest claims and better products.
The firmware and hardware are part of the algorithm
Software engineers sometimes think of firmware and hardware as fixed constraints — the algorithm runs on top of them, and the job is to make the algorithm work within those constraints.
This framing is wrong for health sensing. The hardware and firmware are part of the sensing system. Sensor placement, sampling rate, signal conditioning, and power management all affect what signal you have to work with. The best algorithm in the world can’t recover information that the hardware didn’t capture.
This means health sensing teams need close integration between hardware, firmware, and algorithm development. Decisions made early in the hardware design have implications that appear months later in algorithm performance.
Personalization is an engineering problem
Population-level algorithms work poorly for individuals. What’s normal for one person isn’t normal for another, and the difference can be large enough to make a population-level model clinically meaningless for specific individuals.
Personalization — adapting models to the individual based on their own longitudinal data — is the right direction. But it introduces a set of engineering problems that most teams underestimate.
Where does personalization happen? On-device, to preserve privacy, means constraints on compute and memory. In the cloud means data transfer and storage at scale. Both create system design challenges that compound over time.
How do you validate that personalization is working? You need ground truth, which is hard to acquire. You need to detect when personalization has gone wrong. You need to handle the case where a person’s baseline changes legitimately versus pathologically.
These are solvable problems, but they require intentional investment.
What scales differ from what ships
The hardest lesson of building health sensing at scale is that what works in a small deployment often fails to generalize. The failure mode is usually not catastrophic — it’s gradual. Edge cases accumulate. Accuracy degrades on users who don’t look like your early adopters. Support burden grows.
The solution is to invest in measurement infrastructure early. Know what your system is doing in production. Monitor accuracy proxies continuously. Build feedback loops that surface edge cases before they become customer problems.
Health sensing is too important to get wrong quietly. Build the systems that tell you when you’re getting it wrong.