Protecting Data: Threat Modeling for Small Teams

Search for a command to run...

No comments yet. Be the first to comment.
A 12-part series on building a privacy-first, accessibility-first, offline-first health PWA.
It’s easy to ship a screen that “looks fine” and still blocks someone from completing the task. Testing is how you catch that early, before it becomes a habit. Accessibility isn’t a checklist you complete once. It’s a feedback loop: you test, you lea...
How I built a local first pain tracker around failure safety, user ownership, and the reality of chronic illness.

By CrisisCore Systems Pain Tracker is a private pain tracking app for logging symptoms, spotting flare patterns, and preparing for appointments without creating an account or sending daily records to the cloud. It is built for people who want practic...

Injury didn’t just break my back. It rewrote my personality.

Discovering the Reality of Creating from Survival and How It Can Help Others

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

Privacy threats aren’t abstract. They look like a shared device, a curious coworker, a browser extension with too much access, or an export sent to the wrong place.
Threat modeling doesn’t require a security team. It requires honesty.
For small teams, the goal isn’t “perfect security.” It’s to:
If you’re building for people in pain, “false reassurance” isn’t just a marketing problem. It changes how people use the app.
Start by naming the assets:
Your architecture decisions should flow from the assets, not from trends.
For a privacy-first health PWA, realistic adversaries include:
Be careful with adversaries you can’t solve:
You can mitigate, but you can’t guarantee.
List how data enters and leaves:
Threat modeling becomes simpler when the map is explicit.
Controls that usually pay off for small teams:
Write the claims you can defend:
Avoid claims you can’t:
1) Assets, adversaries, and entry points are written down 2) Top 5 risks have concrete mitigations 3) Logs and analytics do not contain Class A content 4) Export is treated as a boundary crossing 5) Claims are honest and scoped
Next, Part 9 builds a repeatable accessibility testing workflow that doesn’t require a lab: automated checks, keyboard tests, screen readers, and targeted observation.