Skip to content
RepoRanker
CrisisCore-Systems

CrisisCore-Systems/pain-tracker

Credits + grant $3Live in production

Privacy-first, offline-capable pain documentation for people living with chronic pain.

Bridge the gap between patient experience and clinical understanding through comprehensive, secure, and accessible pain tracking technology. A privacy-first, offline-capable PWA for chronic pain management.

★5⑂ 1TypeScriptPush 3mo agoListed 4mo ago10 open issuesMIT

crisiscore-systems.github.io/pain-tracker/

  • TypeScript88.8%
  • JavaScript8.8%
  • CSS1.1%
  • PowerShell0.4%
  • HTML0.4%
  • Shell0.3%
  • PLpgSQL0.2%
  • Makefile0.1%
View on GitHub

$3

$2.60 from converted credits; $0.40 granted by RepoRanker. Credits and grants are not card payments. This placement does not expire. Its rank holds until another repo spends more, and then this one moves down, never off. Taking the top of the board from here costs $16.

Report a problem

1 Review

Pain Tracker stands out because it treats privacy, degraded-mode use, and lived context as core product requirements rather than polish added after the tracking UI. The README does a strong job explaining why a local-first chronic pain tracker matters, and the technical choices back that up: React/TypeScript, Zustand, Zod, IndexedDB, explicit export flows, and optional integrations framed as trust boundaries. I especially liked that the project avoids vague “secure health app” claims and instead documents concrete limits through PRIVACY.md, SECURITY.md, SECURITY_INVARIANTS.md, and the Protective Computing reference material. For a health-adjacent app, that restraint is important.

The repository also shows real maintenance discipline. There are CI/security badges, 223 tracked tests called out in the README, Playwright/Vitest coverage paths, MIT licensing, a code of conduct, contributor docs, and open issues that are actually about improving repo adoption rather than hiding gaps. The architecture docs are unusually thoughtful, especially around local storage, AES-GCM encryption, CSP, WorkSafeBC-oriented exports, and background sync exfiltration risk. That gives contributors a clearer sense of which changes are risky.

The biggest improvement I would make is reducing first-run friction. The repo is impressive but dense: the README, trust docs, security doctrine, SEO resources, release notes, and many scripts can overwhelm a new user who just wants to know “Can I install this safely and track pain today?” A short “happy path” demo section with three screenshots, one install route, and one export example would help. I also noticed a possible setup mismatch: package.json requires Node >=22.12.0 <23, while CONTRIBUTING.md still says Node 20 LTS. Fixing that would prevent a frustrating first contributor experience. Overall, this is a serious, unusually humane open-source health tool with a clear philosophy and strong engineering instincts; the next adoption win is making the entry point as calm and focused as the product’s design values.