A Small Checklist for Apps That Handle Vulnerable User Data

Architecture-level checklist context: health app privacy architecture

A normal web app checklist asks whether the feature works.

A protective checklist asks who gets hurt when it does not.

If you want privacy-first, offline health tech to exist without surveillance funding it: sponsor the build → https://github.com/sponsors/CrisisCore-Systems

Most software reviews focus on function, performance, and bugs. Those matter. But when the app handles vulnerable user data, another layer is required.

The question becomes:

does this system preserve user agency under stress?

What counts as vulnerable user data?

Vulnerable user data is not limited to medical records.

It can include:

• health symptoms
• pain history
• medication notes
• disability documentation
• legal notes
• financial hardship details
• crisis journaling
• identity documents
• private family, housing, or work records

The common feature is not the file type.

The common feature is consequence.

If exposure, loss, confusion, or forced disclosure could materially harm the user, the data deserves a stricter review.

The core checklist

Here is a compact starting point.

This list is not a compliance framework.

It is a product and architecture smell test.

The Protective Computing lens

Protective Computing treats failure modes as part of the product surface.

The app is not only judged by successful use.

It is judged by degraded use.

What happens when the network drops? When the user is interrupted? When the device is shared? When the tab reloads? When export is misunderstood? When support is not available? When an optional subsystem fails?

If those questions sound like edge cases, the product is still assuming stability.

Sensitive apps should not.

PainTracker as a checklist example

PainTracker is one practical example.

That does not make the app perfect.

It makes the boundaries inspectable.

The point of the checklist is not to declare victory. It is to expose where claims need proof.

What still needs work

Honest review should also name unfinished evidence.

For PainTracker, that includes:

• more usability testing
• clearer backup education
• more accessibility review
• more clinician feedback
• more report format testing
• continued degraded-mode verification

Those limitations are not marketing problems.

They are part of the trust model.

If a product claims to be resilient, private, local-first, or user-controlled, it should be clear where the evidence is strong and where it is still developing.

Copyable checklist

Before shipping a sensitive feature, ask:

[ ] What does this feature expose?
[ ] What does it require from the user?
[ ] What happens if the user is interrupted?
[ ] What happens if the network fails?
[ ] What happens if the device is shared?
[ ] What happens if export is misunderstood?
[ ] What happens if the user cannot contact support?
[ ] What is the safest degraded state?

Then answer in terms of system behavior, not intention.

"We care about privacy" is not an answer.

"The record stays local unless the user exports it" is closer.

"The export preview shows what is included before the file is shared" is better.

The useful takeaway

Sensitive apps need a different review posture.

Not only "does it work?"

Also:

what does it expose, lose, demand, or break when the user is under pressure?

I am applying this checklist through PainTracker.ca and the broader Protective Computing work at CrisisCore Systems.

Use it, modify it, critique it.

Support this work

• Sponsor the project (primary): https://github.com/sponsors/CrisisCore-Systems
• Star the repo (secondary): https://github.com/CrisisCore-Systems/pain-tracker