Skip to content
CCCrisisCore Systems
CrisisCore Systems

About

I build systems for people who cannot afford to be failed by systems.

Founder, CrisisCore Systems. Creator of PainTracker. Author of Protective Computing.

My work began in collapse, not comfort. Before CrisisCore Systems, before Protective Computing, before PainTracker, there was a simple problem: most software assumes the user is stable, resourced, regulated, housed, calm, and supported.

I was not.

I came from a trade background as a Red Seal HVAC/R technician, where failure was physical, immediate, and expensive. A bad installation did not become a vague user inconvenience. It became heat loss, pressure failure, safety risk, downtime, and real-world consequence.

That shaped how I see technology.

Software should not just function when everything goes right. It should protect people when everything goes wrong.

After years of injury, instability, legal pressure, housing collapse, chronic pain, and trying to rebuild under conditions most systems are not designed to understand, I started building tools from the failure edge inward. Not wellness apps for ideal users. Not productivity dashboards for people already in control. Tools for the moment where memory breaks, pressure spikes, trust collapses, and the user still needs something that does not betray them.

That became PainTracker.

PainTracker is a privacy-first, offline-capable chronic pain documentation tool designed to help people record symptoms, patterns, flares, medication effects, and reports without forcing their most vulnerable data into someone else’s cloud. It was built around a principle that now defines my work:

The user should remain the authority over their own data, especially when they are under pressure.

From there, I developed the broader framework I call Protective Computing.

Protective Computing is the discipline of designing software that fails safely. It focuses on local authority, reduced exposure, reversible states, clear degradation modes, and trust surfaces that do not collapse the moment a user is stressed, poor, injured, offline, locked out, or dealing with institutional power.

CrisisCore Systems is the studio built around that doctrine.

The work is part engineering, part research, part survival architecture. I build privacy-first tools, audit trust surfaces, document failure modes, and design systems that treat vulnerable users as real users, not edge cases.

I do not come from the clean side of technology. I come from the underside, where systems are tested by poverty, pain, bureaucracy, device loss, unstable housing, legal pressure, and the quiet violence of being told to “just use the app” when the app was never designed for your reality.

That is the origin.

Not a startup fantasy.
A field report.

My goal is simple: build tools that preserve agency when people are already close to losing it.

Because humane software is not software that looks kind.
It is software that does not abandon the user at the exact moment protection matters most.

Why this exists

Products can fail people even when they look fine.

Many products run technically, but they still betray users when the context collapses: memory breaks, trust breaks, devices fail, or the system is no longer safe for the person using it.

I find those failure edges early, explain them plainly, and turn them into fixes the team can ship without creating more brittle defaults.

This is service work first: trust review, correction, and implementation support rooted in real conditions, not ideal assumptions.

What I do
  • Trust review before launch or buyer inspection.
  • Failure-mode and boundary review for local-first, offline-capable systems.
  • Privacy and evidence design that holds up under pressure.
Founder profile

Founder of CrisisCore Systems. Independent systems designer with a trade background in Red Seal HVAC/R and lived experience building for people who are already under pressure.

Engagement

I work best asynchronously and artifact-first. A short written context, a few constraints, and links beat a long call.

If coercion risk, compromised devices, legal exposure, or health-adjacent data are in play, say so early. That changes the review from the start.

Operational note: avoid sending sensitive personal data by email. If you need a safer channel, say so in the first message.
Next step

Open the case-study route when you want proof and operational detail. Use the trust read when you need the simplest, fastest answer about risk and fit.