Lessons Learned from PainTracker
I’m the developer behind CrisisCore-Systems and Pain Tracker – a privacy-first, offline-first pain journal built for people who’ve been failed by “normal” health apps. I build PWAs that run entirely on your device, use real encryption, and respect trauma and crisis instead of exploiting them. Here I write about Web Crypto, IndexedDB, workers’ comp evidence, and building software from collapse.
After you ship, the most valuable lessons are rarely the technical ones. They’re the ones about what users actually need when life is hard.
A retrospective is only useful if it names the tradeoffs.
If you’re building anything “health-adjacent,” you will feel pressure to optimize for growth, engagement, or novelty. PainTracker pushed in the opposite direction: optimize for trust, clarity, and usability on the worst day.
PainTracker’s guiding lessons (the ones that generalize):
1) Trust is an architecture decision
Privacy-first isn’t a policy page. It’s local-first defaults, explicit boundaries, and honest claims.
If users suspect surveillance, they will self-censor. The tool becomes less useful and more harmful.
2) Accessibility is what makes the data real
If the UI isn’t usable on bad days, you won’t get the data that matters.
The “best” model and “best” analytics are irrelevant if the user can’t log quickly, recover from errors, and understand the system state.
3) Exports are the bridge to real-world outcomes
For many users, the value of tracking is not self-optimization. It’s communication:
- with clinicians
- with employers
- with claims systems
Designing for clean, user-controlled exports is how the app helps beyond the screen.
4) The app must fail gently
Offline, quota limits, crashes, and updates will happen.
The difference between a trustworthy tool and a harmful one is whether failure:
- preserves work
- explains what happened
- offers a recovery path
A distilled checklist (carry this to any project)
1) Local-first by default (offline is normal) 2) Minimal data collection (only what earns its place) 3) A11y is continuous (keyboard, screen reader, low-friction) 4) Export is explicit and user-controlled 5) Logs are non-reconstructive (no sensitive content) 6) Failure modes have gentle recoveries 7) Claims are honest and scoped
If you build around this checklist, you’ll ship something that respects users under real constraints.
That’s the bar. Not “feature-rich.” Not “sticky.” Just: reliable, understandable, and safe.
