3 ms·

Zero-cloud pain tracker with local encryption, built after injury

crisiscore_sys 8mo ago
I built this because I ran into a problem that felt bigger than software. 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 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.

I built this because I ran into a problem that felt bigger than software. 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 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.