After a spinal injury, a lot of my life collapsed at once — work, stability, routine, and eventually housing. During that time, I was also trying to document chronic pain in a way doctors and insurers would actually take seriously.
Every pain-tracking app I tried had the same assumptions:
your data belongs in the cloud
you’ll always have connectivity
you’re calm enough to navigate complex UI
privacy is a policy, not an architecture
None of that matched real life in unstable conditions.
So I started building a different model: a privacy-first, offline-capable Progressive Web App designed around trauma, instability, and limited energy — not ideal environments.
Key constraints I treated as non-negotiable:
Zero cloud storage — data stays on the device unless the user exports it
Client-side AES-GCM encryption for all persisted records
100% offline clinical assessment capability
No accounts, analytics, or tracking
Open-source code for inspection, not trust-me privacy claims
The goal wasn’t a wellness app. It was something closer to a local documentation tool that survives when infrastructure doesn’t.
I wrote a full technical whitepaper covering:
threat model and adversarial assumptions
local-first encrypted data flow
offline service-worker guarantees
clinical boundary disclaimers (not a medical device)
honest limits of zero-cloud design
That’s here:
https://www.paintracker.ca/whitepaper
The live app and source are small and early, but functional. Right now I’m mainly interested in technical and ethical scrutiny, especially from people who think:
zero-cloud health software is necessary
or completely unrealistic
Both perspectives are useful.
If nothing else, I wanted to test a simple question:
Can clinically useful health software exist without extracting user data or depending on constant connectivity?
I’m still figuring out the answer.
Feedback welcome.