Thanks Varsha, exactly. That gap between demo success and failure safety is where a lot of trust claims collapse. A health app can look polished, have clean onboarding, nice charts, and strong privacy language, but if the user loses access at the wrong moment, or an export fails when they need evidence for a doctor, insurer, or benefits claim, the architecture has quietly moved the burden back onto the person already under pressure. That is why I keep framing this as a systems problem, not just a UX or compliance problem. The real trust test is not “does this work when everything is normal?” It is “what does this system preserve when the user is not okay?”

Exactly. The moment real people depend on it, the project stops being a portfolio piece and starts becoming an engineering system. That pressure exposes everything tutorials hide: confusing UX, missing fallbacks, weak error handling, accessibility gaps, unclear trust signals, and the parts of the app that only break when someone is tired, stressed, or using it in a real situation. That is the difference between building something that looks good and building something that holds up.

This is exactly what building PainTracker.ca forced me to understand. The first version can be clean. The code can be fine. The layout can look decent. And it can still mean almost nothing until real people start touching it. Once people are actually logging pain, the whole system changes. Suddenly the edge cases are not theoretical. Accessibility gaps matter. Slow screens matter. Confusing flows matter. Export problems matter. A person might be in a flare, exhausted, stressed, or trying to prepare something for a doctor. That teaches you more than another polished demo ever will. Real users turn your project from code into responsibility. That is where the engineering actually starts.

Appreciate that. That is the distinction more teams need to take seriously. AI can help generate options, but it cannot absorb the ethical cost of a bad architectural choice. In health software, the failure case is not abstract. It can mean lost records, inaccessible exports, account lockout, broken continuity of care, or sensitive data becoming harder to control. That is why I keep coming back to the same question: Does this architecture still protect the user when life gets unstable? That question changes the design conversation fast.

This connects to something I keep running into with health software: the default architecture often decides the trust model before the user ever gets a real choice. AI is very good at the happy path. It generates auth flows, CRUD shapes, and readable error messages. Where it consistently underperforms is at the failure edge: what happens to the user when the database is unavailable, when the session expires mid-action, when the export fails silently, when recovery requires contacting support. For apps handling sensitive data, those failure modes are not edge cases. They are the moment the architecture either protects the user or transfers cost onto them. A lot of teams treat "stable" as equivalent to "works in demos." The real test is: what does the app do to a vulnerable user when it fails? That is a question AI tooling almost never gets asked to answer.

This connects to something I keep running into with health software: the default architecture often decides the trust model before the user ever gets a real choice. AI tools are great at pattern-matching and execution speed. But architecture is about failure modes, not happy paths. What happens when the database grows past expectations? What happens when the user loses their credentials? What happens when the company pivots and the storage model changes? For health tools especially, those failure modes transfer cost directly onto users who may not be in a position to absorb the disruption. That makes architectural decisions a safety question, not just a scalability question. A lot of apps treat cloud storage as the neutral default. But for sensitive data it is not neutral. It changes the risk surface, the recovery model, the breach impact, and the user's dependence on the company staying alive. Local-first is not always the answer, but it should be considered much earlier than most teams consider it.

This connects to something I keep running into with health software specifically: the default architecture often decides the trust model before the user ever gets a real choice. Cloud APIs for AI feel low-friction until you map out what is actually leaving the device. For health data, legal evidence, or anything involving a vulnerable user, that exit point is not neutral. It changes the breach surface, the recovery options, and what happens to the user when the company changes its terms or gets acquired. Local-first is not always the right answer for AI inference. But the question of what stays on device and what leaves should be an intentional design decision, not a default. I wrote about this from the health-data side today because I ran into the same problem building PainTracker. https://blog.paintracker.ca/stop-putting-health-data-in-the-cloud-by-default

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.

For anyone curious about the technical implementation: The full stack is: PWA (Progressive Web App) with offline-first Service Worker caching IndexedDB for local, persistent, structured storage Web Crypto API (AES-GCM encryption, PBKDF2 key derivation) for optional local encryption Service Worker for offline routing and asset caching Local-first storage by default, no required account, no server-side health database Optional export (JSON/PDF) so data is portable and not locked in The key design decision: every feature was evaluated against the question "what happens when this fails at 2am while the user is in a flare?" If the failure punished the user, the design changed. Open source at github.com/CrisisCore-Systems