Shipping, Observability, and Incident Handling
When something goes wrong in a health tool, the user can lose trust and momentum. Your job is to fix problems without turning the app into surveillance.
Shipping a health-adjacent tool is different from shipping a hobby app.
Reliability is part of care.
And when something breaks, the fix has to respect privacy while still being useful.
But “observability” in a privacy-first app must be handled carefully. The fastest way to betray trust is to quietly collect sensitive information in logs or analytics.
What you can observe without surveillance
A safe observability posture focuses on:
- app health (crashes, failed writes, migration failures)
- performance (slow screens, long operations)
- security-relevant events (without sensitive payloads)
And avoids:
- capturing raw notes
- capturing export content
- capturing entry payloads
Errors: make them useful, not revealing
Error handling should:
- show non-shaming messages
- preserve user work
- log only what you need to debug (operation name, error type, coarse counts)
If a log line could reconstruct a user’s health entry, it’s too detailed.
Analytics boundaries (if you ever add them)
In a privacy-first health context:
- default is no telemetry
- any analytics must be explicit opt-in
- analytics must be content-free (no Class A)
If you can’t describe the boundary clearly, don’t ship analytics.
Incidents: treat them as learning, not blame
An incident can be:
- data loss risk (migration bug)
- privacy risk (export confusion, unintended disclosure)
- reliability risk (save failures)
Small-team incident loop:
1) Triage: what happened and who is affected? 2) Contain: stop the bleeding (disable feature, add guardrails) 3) Recover: provide user-facing steps 4) Learn: add tests and update the checklist
Shipping quick check
1) Primary flows have explicit error states and recovery paths 2) Logs are redacted and non-reconstructive 3) No default telemetry; any analytics is opt-in and documented 4) A basic incident playbook exists 5) Releases are tested on at least one real device form factor
Next: Part 11 — From PWA to Native: When and How to Branch
Next, Part 11 defines when a PWA is enough and when native becomes worth it, plus how to structure code so you can branch without rewriting your product.
