---
title: "Discussion on \"Stop Putting Health Data in the Cloud by Default\" | Hashnode"
description: "Discussion on \"Stop Putting Health Data in the Cloud by Default\". How I built a local first pain tracker around failure safety, user ownership, and the reality of chronic illness."
url: "https://hashnode.com/posts/stop-putting-health-data-in-the-cloud-by-default/6a039a05937b84f779d090eb"
---

[Feed](https://hashnode.com/feed) /

Discussion

# [Stop Putting Health Data in the Cloud by Default](https://blog.paintracker.ca/stop-putting-health-data-in-the-cloud-by-default?utm_source=hashnode&utm_medium=feed)

How I built a local first pain tracker around failure safety, user ownership, and the reality of chronic illness.

May 12 · 5 min read · blog.paintracker.ca  
Read the article

-   [#pwa](https://hashnode.com/tag/pwa)
-   [#privacy](https://hashnode.com/tag/privacy)
-   [#healthtech](https://hashnode.com/tag/healthtech)
-   [#webdev](https://hashnode.com/tag/webdev)
-   [#indexeddb](https://hashnode.com/tag/indexeddb)

## Written by

[CrisisCore-Systems](https://hashnode.com/@CrisisCoreSystems)

@CrisisCoreSystems · Vernon, BC, Canada

  
[View profile](https://hashnode.com/@CrisisCoreSystems)

Building privacy first health tools that fail safely when users are already under pressure.

I’m the founder of CrisisCore Systems and the developer behind PainTracker.ca, 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 that still works when life doesn’t.

## Responses 1

Markdown supported · ⌘↵ to post

[CrisisCore-Systems](https://hashnode.com/@CrisisCoreSystems)

[May 12](https://hashnode.com/posts/stop-putting-health-data-in-the-cloud-by-default/6a039a05937b84f779d090eb/comment/6a03a00e937b84f779d2ffbe)

Technical stack behind this build, for anyone who wants to dig in:

PWA (installable, offline behavior via manifest + service worker) IndexedDB for local structured storage — entries stay on device by default Service Worker for static asset caching and offline reliability Web Crypto for client-side encryption paths User-initiated export instead of forced cloud sync No required account for the core tracker

The stack decisions are not just technical preferences. Each one is a response to a specific failure mode.

IndexedDB instead of a remote database: if the server goes down, the user does not lose access to their own health records. No required account: a user in a flare at 2am can log symptoms without a password reset flow blocking them. User-controlled export: the user owns the data format, not the platform.

The bigger design question I am still working through: what does "safe to fail" actually mean for software used by people who are already in pain, cognitively impaired, or under medical or legal pressure?

That is the question I want feedback on most.