---
title: "Comment by CrisisCore-Systems on \"Stop Putting Health Data in the Cloud by Default\" | Hashnode"
description: "Technical stack behind this build, for anyone who wants to dig in: PWA (installable, offline behavior via manifest + service worker) IndexedDB for local structu"
url: "https://hashnode.com/posts/stop-putting-health-data-in-the-cloud-by-default/6a039a05937b84f779d090eb/comment/6a03a00e937b84f779d2ffbe"
---

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

Comment [Stop Putting Health Data in the Cloud by Default](https://hashnode.com/posts/stop-putting-health-data-in-the-cloud-by-default/6a039a05937b84f779d090eb)

[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.