Heartware: The Wearable I Almost Built

In 2014, we built a wearable for autism. We called it Heartware — the device sat at the chest, close to the heart, and the problem it was designed to address was fundamentally human.

The technology was primitive by today's standards. The clinical insight was not.

For individuals with High Functioning Autism, the clinical system in 2014 offered two primary interventions: antipsychotic medication and therapy. Both had clinical value. Neither could do what mattered most — meet people in the moment, in their daily life, where the difficulty was actually happening.

HFA individuals face a specific and under-served challenge: sensory triggers cause emotional dysregulation without warning, and the physiological response often precedes conscious awareness. By the time a person understands they are overwhelmed, the moment has passed — or the situation has already escalated. The system had no mechanism for real-time support.

A psychologist we interviewed during user research named the gap precisely:

"There is real value to bridge the understanding of WHY they feel this way, to WHAT they can do to resolve it." — Ms. Chen, Psychologist (user research, 2014)

That became the design brief: a bridge from physiological trigger to self-regulation response. Not a medication. Not a therapy session. A system that worked in real time, in context, with the person.

We opened our pitch with a film called Carly's Cafe — two minutes inside the sensory experience of autism. First title card: "Autism has locked me inside a body I cannot control."

That was the problem. That was the gap.

The device — we called it Kerbie — was a small wearable worn at the chest. The design was intentional: a clean adult form for workplace settings, with an interchangeable faceplate for children that made it look like a companion rather than a medical device.

Three sensors worked in combination.

ECG and heart rate variability for physiological baseline and spike detection. The research foundation was solid — published academic work showed 70% classification accuracy across five emotional states, and 98% accuracy for two (happiness and sadness) using frequency-band analysis of ECG signals. This wasn't guesswork. It was engineering built on clinical research.

Skin temperature as a secondary stress indicator. And a front-facing camera to capture environmental context at the moment of a trigger — what was the person seeing when it happened?

That combination was the architectural insight: biometric data and environmental data, captured simultaneously at the moment of dysregulation. Most systems captured one or the other. Heartware captured both.

The mobile app gave the user real-time visibility into their current state. When a trigger was detected, it surfaced their personal toolkit — customisable interventions they had pre-set: five deep breaths, a five-minute walk, a visualisation exercise, calling an emergency contact. The bridge from WHY to WHAT, made actionable.

The web dashboard had two views. The self view — "here is a snapshot of how you are doing" — gave the individual their own data: triggers this week, percentage resolved, patterns over time, which days were hardest. The caregiver view surfaced the same information for a parent or support worker, calibrated for their role.

The individual owned their data and their plan. The carer got visibility without control. That split was a deliberate structural position. Not a product decision — a position on how technology should sit in a care relationship.

We placed in the top ten at the Enabling Community Colab hackathon in Singapore. Won a development grant. Attracted interest from a startup studio with a model I found genuinely compelling — not just capital, but mentorship, design thinking, and a protected environment to build something real.

I was 26. My first serious attempt at building something of my own.

Three months later, it was over. The co-founding team broke apart before the prototype was finished. The IP stayed with us intact.

Then came the decision I'm most honest about. The team pivoted — to a dining app, then a salon app. As far from anything I believed in as you can get. I went along with it. I could have walked away and continued Heartware alone. I didn't. I followed the momentum rather than returning to what I knew was true.

I haven't spoken to the team since. The Heartware IP stayed with me. I just never picked it up.

I went back to building infrastructure.

A decade working on IoT systems for elderly care — scaled to 3,000+ homes as part of Singapore's Smart Nation programme — clinical data trials with government hospitals, building the quality management systems required to certify software as a medical device. The work was different from Heartware in form, but not in conviction: technology as infrastructure for care, not as isolated product.

By 2020, I was based in Toronto, managing clinical infrastructure projects across three time zones — writing about what a patient-centred health platform would actually look like. The data layer, the portability, the continuous monitoring architecture. Not advocacy. Analysis. The thesis was already formed. The proof came later.

This year I moved to Melbourne. The clinical platform I'd been building remotely since 2020 became the proving ground — prescribing, dispensing, patient records, multiple care pathways, all running on shared infrastructure. The same conviction, now running at a different scale.

Last year I wrote a post comparing the Humane AI Pin to Heartware — the architectural parallels were striking. One of the original investors replied:

"The product has stayed with me all these years. It is one of those products that would add so much value and really make a difference. If you do pick it up, please reach out, would love to be a part of doing things right."

Not because it reopened something. Because it confirmed what I already suspected — the architecture was right. The timing was wrong. The person carrying it wasn't ready.

The architecture we sketched that weekend — persistent biometric monitoring, environmental context capture, real-time feedback loop, individual agency plus caregiver visibility, personalised intervention system — is structurally identical to what the largest health platforms in the world are now racing to build.

CVS Health just launched Health100 with Google Cloud — an agentic AI platform designed to be an always-on personal healthcare partner. Apple is running longitudinal health studies through its wearables and pushing clinician-integrated health tools beyond the consumer layer. Google's MedGemma models are being deployed for clinical decision support, triage, and patient interviewing across health systems from India to Singapore.

The sensor technology has matured. Apple Watch and continuous glucose monitors do passively what required a custom hardware prototype in 2014. The edge ML layer that makes reliable pattern recognition possible now exists on consumer devices.

We were early. Not wrong.

If I were to rebuild Heartware today, the architecture would shift in three ways.

Software-first, hardware-optional. The 2014 version required a proprietary device because nothing else existed. Today the biometric data flows from Apple Watch, Garmin, or any clinical-grade wearable — platforms already in the hands of millions. There is still merit in purpose-built hardware for specific clinical populations, but the cost to develop and certify a niche device is prohibitive as a starting point. The software layer — pattern recognition, intervention routing, clinical reporting — is where the value lives. Start there. Let the hardware question answer itself.

Clinical integration from day one. The 2014 caregiver dashboard was disconnected from the clinical system. The data didn't flow to a GP, a psychiatrist, or a support worker's professional record. A 2026 version would be built for clinical interoperability from the ground up — the data moving with the patient, not sitting isolated in an app.

AI replacing the dashboard. Rather than surfacing data for the user to interpret, an AI layer processes patterns in the background and surfaces only what is contextually relevant. The individual sees support, not monitoring. Less data. More signal. Less friction. More presence.

This is, essentially, what the major health platforms are racing to build for the general population in 2026. Heartware in 2014 was a specific solution for a specific population. The architecture underlying it was universal.

That thesis hasn't changed. The infrastructure to prove it finally exists.

Whether Heartware gets rebuilt is a question I'm still sitting with. What I know is that the conviction it was born from — that patients need a continuous layer between them and their care, not just episodic appointments and prescriptions — is the same conviction driving everything I build now. It was true in a hackathon room in Singapore in 2014. It's true in the clinical platform I'm building in Melbourne in 2026.

Some ideas need time. Not to be validated — to find the person ready to carry them.