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

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.