What We Learned Shipping a Connected Healthtech Product: Notes from the Tablet, the Sensor, and the Cloud

In healthtech, the easiest mistakes to make are also the most expensive. They tend not to look like mistakes at first. A session ID that is technically a string. A timestamp that is approximately correct. A video that loads in three seconds instead of being embedded. An exit button that does not return to the host app. Individually, each of these is a small line item on a backlog. Together, they decide whether a product can be demoed to a paying customer or whether it cannot.

Over the past year we inherited a connected fitness and rehabilitation system from a previous development team and brought it to a demo-ready, customer-facing state. I want to share the lessons that came out of that work, because almost none of them are specific to the product. They show up every time a serious healthtech company tries to move from a working prototype to something a clinician, a coach, or a customer can actually touch.

I have left the client and product names out of this on purpose. The point is not who. The point is what a cloud plus device product needs to clear before it earns trust.

The Shape of the Problem

The product we worked on follows a pattern that is now common in healthtech and connected fitness: a tablet application that guides the user through a session, a set of body-worn IMU sensors that capture motion data, a companion application from the sensor vendor that handles the upload, and a cloud backend that runs signal processing on the captured data and returns a useful output (a recap, a chart, a structured export).

The hard part of this kind of system is that no single piece is hard on its own. The tablet app is a relatively standard guided experience. The sensors are off the shelf. The cloud pipeline is solvable with the usual tools. What is hard is the choreography between them. Every handoff is a potential failure mode. Every assumption one component makes about another is a place where reality eventually disagrees.

The system we received had been built in a way that the individual pieces worked, but the choreography did not. The first job was to figure out which of those broken handoffs mattered and which did not.

Two Fixes That Unlocked Everything

Most engineering teams know the feeling of looking at a backlog of forty issues and trying to decide which ones really move the product. In this case, two issues moved it.

The first was that session identifiers were not unique. When a user completed a workout, the system generated an ID. When the same user completed the same workout a second time, the system generated the same ID. From the user's point of view, nothing was wrong. From the data point of view, every session was overwriting the last one, and weeks of captured signal data was effectively a single record.

The second was that the timestamps embedded in the session metadata drifted from real time as the session progressed. They started off close. By the end of a thirty minute workout, they were tens of seconds off. The cloud signal processing pipeline used these timestamps to align the IMU data with the exercises the user was supposed to be performing. Small errors were recoverable. Large errors were not.

These were not glamorous bugs. They were not in any user interface. No one would notice them in a five minute walkthrough. But they were the difference between a system that produced clean, attributable, comparable data per user, per session, and a system that produced an indistinguishable smear.

In healthtech, data integrity is not a feature you add later. It is the product. The minute the data stops being attributable to a specific session, by a specific user, in a specific order, the entire downstream value collapses. The pipeline can be elegant. The visualisations can be beautiful. None of it matters if the inputs were already overwritten.

We fixed both issues early, and the moment they were fixed the rest of the system became analyseable. That is usually how it goes. Two correct bug fixes can unlock months of work that was previously blocked without anyone realising it was blocked.

What "Demo Ready" Actually Means

The second lesson is one we keep relearning across healthtech engagements. The bar for "the system works in the office" and the bar for "the system can be shown to a paying customer on their site" are not the same bar. They are not even on the same chart.

A demo on-site means standing in a pool deck, a clinic, a gym, or a hospital corridor, holding a tablet, with a sensor strapped to a person, in front of someone who is deciding whether to give you money. In that moment, three things matter that did not matter in the office.

First, the network is unreliable. The exercise videos that loaded fine over office wifi will hang on a guest network. We moved the media for the demo sessions out of the streaming path entirely. We replaced video files with embedded GIFs where the loss in visual quality was negligible and the gain in determinism was significant. We pre-built three or four sessions, downloaded the media to the device, and made sure the demo path did not depend on a single fresh network request after the user started.

Second, the visual environment is hostile. The exercise timer that was perfectly readable on a desk did not work when the person doing the exercise was a metre or two away from the screen, often moving, often with water or sweat or sunlight involved. We made the timer dramatically larger. This is the kind of fix that does not show up in any architecture diagram and is the most important one in the room when the demo is happening.

Third, the device chain has to behave. The companion application from the sensor vendor was supposed to return to the host app after upload. It did not always do that. To a user, this looks like the entire system has crashed. To a developer, this is a documented edge case. To a sales engineer, this is the demo being lost. We patched the integration so that the user always ended back in the host app, regardless of what the sensor companion thought it was doing.

None of these fixes is glamorous. All of them are the difference between closing a deal and losing one.

The Output Is the Product

The session itself, from the operator's point of view, is almost invisible. The thing the clinician, the coach, or the analyst actually uses is whatever the system produces afterwards. The recap. The chart. The exportable record. The summary that tells them whether the person they are working with is improving, plateauing, or compensating.

We spent significant effort on the output layer. A single web page, a PDF, a CSV, a structured object. The shape mattered less than the fact that there was a clean, repeatable, exportable artifact at the end of every session.

This is something connected health products often underinvest in. The team builds the capture experience and the signal processing pipeline, and the output is treated as an afterthought. In our experience, the output is what the customer actually pays for. The capture is the cost of producing it.

If you are building a connected healthtech product and your output layer is a hardcoded screen with a single chart, that is the first place to invest. Not the most flattering advice for a team that just spent eighteen months on the signal processing, but it is consistently the right call.

Cloud Plus Device Is a Different Discipline

A lot of the value we have been building at Buildcon sits in the intersection between cloud applications and physical devices. Our ideal engagement is exactly this kind of system: a software stack that includes a mobile or tablet client, integrates with sensors or other hardware over Bluetooth or a sensor companion, processes the captured data in the cloud, and returns a useful artifact to a clinician, an athlete, or an operator.

What we have learned, again and again, is that this discipline does not reward generalists. Pure cloud teams underestimate how fragile the device chain is. Pure mobile teams underestimate the cloud and data integrity requirements. The teams that ship are the ones that hold both ends at the same time, and that treat the handoff between them as a first class concern rather than an integration detail.

A few principles we apply now by default on these engagements:

Treat every cross-boundary identifier as load-bearing. Session IDs, user IDs, device IDs, capture IDs. If any of them are non-unique, ambiguous, or reusable, the data layer is already broken.

Treat timestamps as a contract, not a convenience. Decide where time comes from. Decide how it is synchronised. Decide what happens when it drifts. Do this before you write any of the processing code.

Plan for the demo environment, not the office environment. Embed media. Pre-build sessions. Cache aggressively. Assume the network will fail at the worst possible moment.

Make the output the product. Whatever leaves the cloud at the end of a session, the recap, the chart, the export, deserves the same care as the capture itself.

Treat the companion apps and SDKs you depend on as third party risk. They will have bugs. They will not behave the way the documentation says. Build defensively at the boundary.

What Inheriting Code Teaches You

There is one more pattern worth naming. Healthtech products often pass through more than one development team. The product we inherited had been touched by at least one prior team. We have seen the same in other engagements.

When you inherit code, the temptation is to rewrite. The discipline is to triage. Most of what is there usually works. The two or three issues that are blocking real progress are usually buried under the things that are obviously ugly but not actually blocking. Spending the first month rewriting the obviously ugly parts is the most expensive way to look productive without delivering anything.

The right move on an inherited codebase is to find the smallest set of changes that unblock the customer journey, ship those, earn the trust, and then negotiate the larger rewrite from a position where you have already delivered value. That is what unlocks the rest of the engagement.

Closing Note

The arc of this engagement was simple. We inherited a system that mostly worked but was not demo-ready. We fixed two pieces of data integrity that nobody outside engineering would have prioritised. We rebuilt the demo path to survive a real customer environment. We invested in the output. We held the cloud and the device sides of the system together. And we moved the product from a state where the team was nervous to put it in front of a customer to a state where the team was happy to.

There is nothing exotic about any of this. The lesson is that healthtech, especially in the connected device space, rewards teams that take the unglamorous parts of the system seriously. The session ID. The timestamp. The timer size. The pre-cached video. The exit button. The export format.

If you are building something in this space, those are the parts to obsess over. Everything else follows from getting them right.