PulihGo

All Feature

Inspiration:

Stroke is one of the leading causes of long-term disability worldwide, and most survivors are told the same thing on discharge: keep doing your hand and arm exercises at home, every day, for months. In practice, that's where recovery often stalls — patients lose motivation without feedback, caregivers aren't trained physiotherapists, and clinic-based rehab equipment is expensive and inaccessible outside major cities. We wanted to see how far a smartphone's built-in gyroscope — a sensor already validated in prior research for measuring range of motion almost as accurately as clinical inclinometers — could go toward closing that gap, without pretending software can replace a therapist.

What it does:

PulihGo turns a smartphone into a guided home rehab companion for post-stroke patients, starting with two forearm movement types: pronation/supination and flexion/extension. The phone is strapped to the forearm and tracks motion in real time via gyroscope, counting reps and range of motion against a clinically-informed target — then wraps that in a simple, encouraging UI so patients stay motivated to keep going.

What sets it apart from "just another exercise counter" is the safety layer built around it:

Pre-Session Pain Check + Stop Rule — before and during each session, a simple none/mild/stop pain check (mapped internally to Numeric Rating Scale thresholds) can halt a session before it causes harm. ROM Ceiling (Safety Cap) — each user gets a progressive range-of-motion limit rather than being pushed toward a generic "normal" range on day one, with the system warning rather than silently letting the patient overextend.

How we built it:

We started by locking down a precise exercise spec rather than building loosely: exact joint angles, neutral position, rep-counting logic (peak-and-return with noise thresholds), and pain-check UI states — all defined before writing product code, so the whole team built against the same numbers.

The safety mechanisms were the part we treated most carefully. We did a literature pass specifically to back two design decisions that started as pure assumptions: the pain-check stop rule (grounded in NRS pain-scale cutoff research) and the ROM ceiling (inspired by progressive range-limiting principles used in rehabilitation robotics/exoskeletons, adapted into a software detection-and-feedback model since a phone obviously can't physically restrain a limb the way a motorized exoskeleton can).

Challenges we ran into

The exoskeleton research doesn't map 1:1 to a phone app. Those papers back mechanical ROM limits enforced by motors; PulihGo can only detect and warn. We had to be explicit — internally and in how we frame the pitch — that we're adapting a design principle, not claiming hardware-equivalent safety. No single consensus pain-scale cutoff exists. Different studies put the "moderate/severe" boundary anywhere from NRS 4 to NRS 6. We picked a conservative ≥6 threshold based on the largest validated sample we found, and documented why, so we have a defensible answer if a judge asks "why this number." Sensor axis mapping isn't something you can assume from documentation. Pitch/roll/yaw behavior depends on exactly how the phone is physically strapped to the forearm, so it had to be verified live on-device rather than hardcoded from a spec sheet.

What we learned

That building a genuinely safe health tool means writing down your limitations as carefully as your features. Every safety mechanism we shipped came with an equally important "here's what this does NOT do" note — and being upfront about that made the product more trustworthy, not less impressive.

What's next for PulihGo

Expanding beyond the two MVP movement types to a fuller exercise library, exploring wearable integration beyond phone-strap tracking, and — most importantly — validating the ROM/pain-gating thresholds with actual clinicians rather than adapted literature alone.