Skip to Content

The Development of a Medical Emergency Alert Product, and Why We Chose to Develop a Smartwatch




Building the Value of Reassurance


Designing a watch that quietly connected lives, care, and systems

It started, as many ideas do, with a simple question:

What’s the value of knowing someone you care for is okay, even when you’re far away?

For many families in the UK, distance is a fact of life.

Grown children often move to cities to follow their careers. Their parents, often active, often independent, live in the countryside, On the farm, in seaside towns, or in the homes they’ve always known. Mobile networks are patchy. Lives are busy. But the worry is always there, in the background.

The product we helped bring to life was designed to answer that worry, not with noise or drama, but with confidence.

It was a smartwatch, built to detect serious health events and raise the alarm without requiring a mobile signal or paired phone. It used a dedicated low-power network for emergencies, and Bluetooth (BLE) for everyday fitness tracking data transfers. It was discreet, designed for the fashion conscious, with dignity in mind, and watch-shaped, not a medical device worn on display. There were some alternatives available in the market, chief among them was a technology that used a wall mounted sensors to monitor movement, usually in a primary room of the house. We had made the decision to use a watch because the sensors and consistent proximity to the wearer’s arm made it possible to be certain when an emergency call had to be made.

For the person wearing it, it offered peace of mind without intrusion.

For the person buying it, usually a son or daughter, it offered a sense of presence, even from far away.

And for the NHS, it offered a system-level benefit: alerts from the watch could be reviewed by The Client Company’s 24/7 operations desk and, if confirmed as genuine, escalated to emergency services through official NHS channels.

The client company, let’s call them Sorella, a venture-backed healthtech startup based in London, had already hired software developers and industrial designers. My role, through AVICT, was to support them as a product and infrastructure strategist.

I was responsible for designing the LoRaWAN network strategy, advising on product features, and shaping the go-to-market approach, from sales and pricing strategy to competitive positioning and hardware trade-offs. I worked with Sorella’s internal teams to evaluate core design choices (watch vs wall-mounted sensor), structure network management and support models, and contribute to the functional requirements of the product and the services surrounding it, based on their market analysis.

I also served as the product manager for the software development initiative, working closely with their team to ensure the feature set was grounded in user needs and market realities.

As with any complex system, the watch was just one part of the offering.

The real value came from how the product, platform, and network fit together, and how they connected to the lives, families, and institutions it was meant to support.

 


Designing for Real Life


Why the network mattered more than the fitness features

Most smartwatches are designed around assumptions.

That you’ll have your phone with you. That you’ll have mobile signal. That emergencies happen where people can see you, or in places with mobile network coverage. Fundamentally the assumption is “If your watch can’t communicate now, it can wait until later”.

But the people this product was designed for don’t always live in those assumptions.

In the UK, it’s common for older adults to live independently, in villages, on farms, or in quiet suburban homes where mobile reception can be unreliable. The person buying the watch, a son, daughter, or relative, might live hundreds of miles away, visiting when they can, but often not close enough to help at a moment’s notice.

The watch itself was discreet and thoughtfully designed, but what made it valuable was its ability to function even when everything else didn’t. That’s why we didn’t depend on mobile networks at all for emergencies. Instead, we would have used LoRaWAN, a long-range, low-power radio protocol designed for exactly these kinds of infrequent, critical transmissions.

Part of my role on the project was to design a network architecture that could support that kind of reliability, even in rural areas or difficult terrain. During the development process we deployed test gateways in London (Canary Wharf and a few Kilometres away at the Marlin Apartments in Southwark) and near Leeds (Pontefract), using a lightweight Linux-based setup with Heltec MT-01 hardware and remote monitoring. These weren’t theoretical placements, they were part of a real-world infrastructure test, integrated into The Things Network to help validate signal strength and delivery latency across actual routes. The software platform was Microsoft Azure VM based in the Bristol data centre.

The watch was configured to keep its LoRa connection silent unless it was needed, preserving battery life and ensuring the network was always clear for true emergencies. For everyday fitness and health data, the device used Bluetooth, syncing via a companion app. This gave users access to step counts, movement trends, and heart rate data, while reserving the LoRa channel for those moments where action, not information, was required.

At the heart of the device was a Nordic nRF52832 microcontroller, a low-power, BLE-capable system-on-chip that allowed us to integrate sensors, handle onboard logic, and manage energy efficiently. It was a well-established platform in the wearable space, known for its reliability in fitness and health applications.

Even in its low-power mode, the system was carefully built to maintain awareness.

Once battery levels dropped below a certain threshold, the screen would power down and non-essential features would shut off, but the accelerometer, heart rate monitor, and GPS receiver stayed online. That way, even on minimal charge, the watch could continue evaluating the wearer’s condition and location, and raise the alarm if things deteriorated.

The value here wasn’t just technical. It was emotional.

It meant that a daughter working in Bristol could go into a meeting knowing that if something happened to her mum in Lincolnshire, someone would know and something was already being done. The system wouldn’t panic. It wouldn’t spam. It would wait, check, and act, only when it mattered most.

That reliability, the quiet kind, was the real product.

And it was our job to make sure that happened not just in one place, but anywhere the watch might be worn.

 

 

A System That Knew When to Speak Up


What happened when the watch decided something was wrong

For most people, wearable technology is about feedback, rings to close, badges to earn, charts to share. Tracking calories burned, Vo2 or maximum heart rate, personal bests, average rates and degree or progress over time.

This watch was different. It wasn’t only designed to keep you engaged.

It was also designed to quietly monitor. It would speak when it had to.

Behind that simplicity, knowing exactly when to get help, was a lot of work.

The device didn’t just react to a single trigger. A stumble, a spike in heart rate, or even total stillness on its own wasn’t enough to justify raising the alarm. That would have created too many false positives. And in healthcare, especially when connected to emergency services, those aren’t just annoying. They’re expensive and potentially keep resources away from those who really need them.

The system was designed to be decisive, not reactive.

In the case of a potential emergency when the data wasn’t conclusive, it performed what we called spot checks, short, multi-sensor evaluations spaced over a few minutes, looking for specific patterns that indicated a real problem.

For example, combinations of:

  • No motion for an extended period, especially in a time window where activity was expected
  • A sustained drop or sudden spike in heart rate without accompanying movement
  • A location that didn’t change, even after one or two mild stimuli (vibration, prompt)

One of the hardest challenges was finding the right combinations of thresholds, logic that could distinguish between someone who had gone to bed early, and someone who had lost consciousness.

We even explored using a thermometer to track sudden changes in body temperature, but it proved too vulnerable to environmental noise, a cold breeze or a warm room could throw the data off. In the end, we stuck with a robust sensor stack focused on motion, heart rate, and GPS, backed by conservative logic that prioritised safety and confidence.

If the watch determined that something was seriously wrong, it could then trigger an alert.

But this wasn’t just a local signal. It triggered a coordinated notification system, with paths that could reach:

  • A single trusted contact
  • A group of people (family members, neighbours, carers)
  • A 24/7 operations desk run by Sorella, where trained staff could evaluate the situation and, if necessary, escalate it to NHS services through official channels

The alerts would include the wearer’s GPS location, and in some cases, optional medical information that had been pre-captured, details that might help a paramedic or A&E doctor respond more quickly and accurately.

We designed the service so that emergency alerts were completely free, there was no subscription, no network fee, and no hidden charges. The infrastructure was kept viable through a hybrid business model: the fitness and wellbeing platform that accompanied the watch offered an optional subscription service.

Users could track steps, heart rate trends, and movement patterns through a simple dashboard, much like Strava or Fitbit. It wasn’t competitive or gamified, but it gave users a sense of engagement and visibility that supported long-term care and quality of life.

And this was key: not everyone would have needed the subscription.

Some users might have wanted nothing more than the safety net. Others could have valued the ability to check in, not to monitor, but to stay connected.

This gave the product flexibility in how it could fit different households, while keeping the core promise free:

If something’s wrong, someone will know. And the system will act.

 


 

A Good Product, Missing a Critical Element


Why knowing someone needs help wasn’t always enough

By the time the platform was functional, the prototypes were tested, and the network infrastructure was proven, the product was doing exactly what it was supposed to. It worked.

It could detect emergencies. It could route alerts to call centre and then on to the NHS. It could send notifications to a family group, include GPS, and preserve its battery in low-power mode to maintain that core emergency function for as long as possible. It could do many of the things that a mid-range fitness smartwatch could do.

But there was one problem it couldn’t solve: what the watch meant.

Technically, it was a beautifully practical solution.

Emotionally, it was more complicated.

Most of the time, the person buying the watch wasn’t the person wearing it.

It was a daughter. A son. A carer. Someone looking for peace of mind, and willing to pay for it. But that didn’t guarantee that their parent or grandparent would want to wear it.

Even though the watch was designed to be attractive and with dignity in mind, handsome cases, gender-specific designs, minimal fuss, the very act of wearing it could feel like a quiet admission. An acknowledgement of vulnerability. A public signal that something might be wrong.

And for many older adults, even those on pensions or benefits, wearable tech already had meaning.

Some already wore Apple Watches, gifted by family. Some tracked their walks on Strava, and shared their progress with friends. These devices carried not just features, but status, they were familiar, admired, and, in some circles, even aspirational.

To ask someone to remove that and wear something new, no matter how useful, was asking more than it would seem.

We weren’t competing on functionality.

We were competing with identity.

And in a surprising number of cases, that was enough to stop the conversation.

It didn’t mean people didn’t see the value. In fact, many testers liked the idea. They liked the way it worked. They appreciated that it was built for them, not borrowed from a fitness market and rebranded.

But adoption is a deeply emotional process.

And when it came to asking someone to put this watch on their wrist, instead of the one their grandson had bought them last Christmas, some people hesitated.

And that hesitation, quietly but firmly, was what eventually shifted the project’s direction.

 

 

From Hardware to Handsets


How the platform found a second life without the watch

When it became clear that adoption was going to be more difficult than expected, not because the product didn’t work, but because people weren’t ready to wear it, the client made a decision.

Rather than push a wearable that risked rejection, that might not sustain its business case and that would be a costly investment and a complex business, they chose to pivot.

The platform stayed. The alerting logic stayed.

But the form factor changed.

The company, “Sorella”, the Italian-backed healthtech startup at the heart of the project, decided to shift its offering toward something that required less behavioural change and less support infrastructure: an app.

Instead of relying on a dedicated device, they developed a smartphone app and Apple Watch companion. It used the same core services:

  • Health and movement tracking
  • Configurable alerts
  • A family dashboard for wellbeing insights
  • Optional emergency escalation through pre-defined contacts

This change allowed the company to distribute the product through familiar channels, app stores, and immediately tap into devices that people already owned, and already valued. It simplified distribution channel needs.

And in many ways, it was a practical step.

There was no longer a need to scale a dedicated LoRaWAN network.

There were fewer barriers to entry for users who already wore a watch they liked. The sales and distribution channels were those of a downloadable digital product rather than a physical one.

And the product could now align with ecosystems that already had cultural weight, iOS, Strava, fitness wearables, and the broader health tech trend.

From a product perspective, the watch became optional, an upgrade path, or a future revisit, rather than the default. And from a commercial perspective, the move created a clear SaaS revenue model, with subscription-based access to dashboards, alerts, and family coordination tools.

For the platform teams, the pivot didn’t erase the work, it repurposed it.

The decisions made about notification routing, medical data packaging, GPS accuracy, and service reliability still applied. They still mattered. And the product that eventually launched was stronger for having been shaped in real-world conditions, with real people in mind.

From a consultancy perspective, our role ended with the hardware and infrastructure.

 

 

The Product You Build Around People


What this project taught us about fit, function, and meaning

Some for products success is difficult to build because the technology is complicated.

For others it’s difficult because the humans are.

This project reminded us of something we’ve seen time and again: even when you get the functionality right, and the business model right, and the infrastructure right… people are still people. They come with history, with pride, with preferences. They make decisions for reasons that don’t always fit neatly into feature sets. Market sizing is critical early in the process.

And that’s what made this project valuable, even beyond the launch.

It wasn’t just about proving a network or delivering a platform.

It was about seeing, first-hand, how dignity and identity and human factors shape the way people adopt technology.

It was about learning where the friction lives, not just in UX, but in emotion. That all the stakeholders play a role in the success of a project.

It was about realising that the most life-saving features in the world won’t matter if they come wrapped in something that makes someone feel “old,” or “watched,” or “dependent.”

From AVICT’s perspective, we supported the client across product design, strategy, infrastructure, support processes, and real-world trade-offs, but more than anything, we helped make sure the whole picture was in view.

We understood that this wasn’t just a watch. It was a service. A reassurance. A relationship.

We worked across disciplines, network design, support structures, competitive positioning, GTM planning, not because it’s clever to span all those things, but because the value only holds when they align.

 

 

Quiet Ideas That Still Have Work to Do


Where the thinking might go next

Not every product initiative ends this way, most end in product launches.

The ideas that shaped this project, attractive hardware, dignity in design, infrastructure that just works, safety without intrusion, still matter. Maybe even more so today than they did at the time.

Because while this particular watch didn’t reach the market, the problem it was trying to solve still exists.

People still live alone. Families still worry. Emergency services still face pressure. And the tension between independence and care still plays out every day, often in silence.

The architecture we helped design, the network, the alerting logic, the support models, is still relevant.

And we’ve seen versions of it emerge in other domains:

  • Remote health monitoring
  • Sensor-driven alerting in vulnerable environments
  • Infrastructure for low-power, event-driven communication
  • Situational products that offer reassurance as a service

Sometimes, those systems are invisible, quietly monitoring, quietly ready.

And that’s the kind of work we’re drawn to.

At AVICT, we often find ourselves working on products that don’t shout.

On things that aren’t trying to win markets with flash, but that solve something real and do it in a way that feels right to the people they’re meant for.

This was one of those projects.

And even though the shape changed, the insight stayed.

So if you’re working on something like that, something that lives in the nuance, we’d love to hear about it.

How Blockchain, IoT, BIM and a Software Platform was Ready to Optimise the Construction Industry