Part of the CrisisCore Build Log – building in public means building honestly.
There are two people living in my body.
The Developer: Architecture-obsessed, relentless, dreams in monorepo structures and cryptographic flows. Shows up to work, ships code, refines schemas until 4 AM.
The Other Guy: Hasn’t been outside in weeks. Can’t remember if he ate today. Might have been crying in the shower this morning but isn’t sure.
Sometimes they trade off mid-sentence.
This blog series has been about Pain Tracker, an open-source chronic pain management application I’ve been building with rigorous attention to encryption, accessibility, and clinical interoperability.
This entry is about why it exists at all.
Origin Story (the real one)
I started this project after moving into a temporary housing situation. No stable residence. Relying on the charity of a relative I hadn’t spoken to in years. The only structure I had was the act of sitting down and opening VS Code.
Pain Tracker wasn’t just a product idea. It was scaffolding. Something to do with my hands while the rest of me was screaming.
The Developer needed something to obsess over. The Other Guy needed something that mattered.
Most days, I don’t know which one is winning. Some days, both show up to the keyboard. Some days, neither does, and I lose 72 hours to static.
The Beast in the Code
The architecture I’ve designed is meant to handle extreme distress states.
Why? Because I was designing it in one.
When I write about trauma-informed UI patterns, progressive disclosure, and crisis detectionthat’s not theoretical empathy. That’s debugging myself in production.
When I build features like:
\ ypescript
interface CrisisState {
detected: boolean;
severity: ‘low’ | ‘moderate’ | ‘high’ | ‘critical’;
suggestedActions: Action[];
safeExitAvailable: boolean;
}
\
I’m not imagining what a distressed user might need. I am that user.
I’m building tools I wish existed when things got bad. And they still get bad.
Not All Days Are Code Days
There’s an entire subsection of tech culture that romanticizes the “grindset.” The 10x engineers. The people who ship 16 hours a day and tweet about it.
Here’s the reality from my codebase:
Some days I:
- Write 2,000 lines.
- Refactor entire modules.
- Design encryption systems that would pass HIPAA audit.
Other days I:
- Stare at a blank terminal for three hours.
- Commit one typo fix.
- Close my laptop and don’t open it again for a week.
Both versions are still building the thing.
The Notebooks I Don’t Show
Behind the public architecture diagrams and blog posts is a stack of handwritten notebooks filled with:
- Scribbled crisis plans
- Brain dumps that look like encrypted gibberish
- Notes to myself like: “Not today. Try again tomorrow.”
That’s not a failure. That’s a crash log. And good systems learn from crash logs.
What I Actually Want to Build
Pain Tracker is a chronic pain management application, yes. But it’s also an attempt to answer a question I’ve been asking since my first breakdown:
Can we build software that doesn’t treat distress as an edge case?
Because distress isn’t rare. It’s the norm for a lot of us. We just pretend otherwise so the happy-path designers don’t have to think about it.
I want:
- Tools that don’t fall apart when the user is falling apart.
- Interfaces that stay calm when the person using them isn’t.
- Infrastructure that keeps working even if I disappear for a week.
That’s not just user-centered design. It’s survivable design.
Build Log Continues
We talk a lot about “building in public.” Usually that means product screenshots and growth charts.
This is my version: architecture diagrams laid next to notebook pages.
The Beast and The Developer running on the same hardware.
Your foundation isn’t defined by how smooth the ground was when you started. It’s defined by how honestly you map the cracks and how stubbornly you reinforce them.
My ground is unstable, fractured, littered with previous collapses.
But it’s mine.
And from that ground, I’m trying to build tools that might make someone else’s terrain a little less lethal.
The story isn’t finished.
If your pages look anything like mine and you’re actively thinking about ending things:
- In Canada, you can call or text 9-8-8 for support.
- Elsewhere, look up your local crisis line or emergency service.
You’re not a defective machine.
You’re a system under extreme load.
Systems can be stabilized.