How We Designed YouMindo's Crisis Safety Features

Most product decisions at YouMindo get debated, shipped, measured, and revised. Crisis safety features don't get that luxury in the same way. If a mood-tracking chart is confusing, a user is annoyed. If a crisis flag doesn't reach anyone, or reaches someone twelve hours too late, the stakes are categorically different. That difference changed how we approached this part of the product from the very first design meeting.

We didn't set out to build something impressive. We set out to build something we could stand behind — explain to a regulator, defend to a clinical advisory board, and trust at 3am when no engineer is watching the system run. That meant making some choices that are, deliberately, less exciting than what a typical product roadmap would produce, and it meant slowing this part of the build down far more than any other part of the product.

Starting from what we wouldn't build

Before we designed anything, we ruled things out. No AI-generated risk score with a confidence percentage nobody could interrogate. No automated message sent to emergency contacts without a person deciding to send it. No feature that made a crisis-adjacent decision on a user's behalf without a human somewhere in the loop. These constraints came from our clinical advisors, not our engineers, and they shaped everything that followed.

The safety plan: a scaffold, not a form

The safety plan is the feature we're proudest of and the one most people never think about, because it's meant to be written before it's ever needed. It's client-authored: YouMindo prompts the questions — personal warning signs, coping strategies that have worked before, people to call, reasons to keep going — but we don't generate any of it. A safety plan you didn't write yourself, in your own language, isn't one you'll trust in a hard moment. Our job is the scaffolding, not the content.

Why we said no to a smarter model

We prototyped a machine-learning classifier for risk detection early on, and it worked better than the simpler system we eventually shipped, at least on our test set. We killed it anyway. A model that flags a conversation based on a weighted combination of signals nobody on the clinical team can fully articulate is a model nobody can defend when a therapist asks 'why did this get flagged?' We wanted a system where the answer to that question is always a complete sentence.

What the keyword system actually looks for

What we shipped instead is deliberately simple: a maintained, clinically-reviewed set of language patterns that indicate someone may be at risk, checked against journal entries and messages with explicit user consent. We won't detail the specifics here — that's by design, not omission — but the principle is that every trigger is known, documented, and auditable. When something is flagged, we can always say exactly why.

The human on the other end

Detection was always the easier half of the problem. The harder half was making sure a flag actually reaches a person who can act on it. Every flagged conversation routes to the client's therapist if they have one, or to an on-call admin reviewer if they don't, with a defined response window. Nothing about the system is automated past that point — no auto-locking the account, no auto-messaging a contact. A human reviews, and a human decides what happens next.

Getting the timing wrong, early on

Our first version of the escalation queue treated every flag with the same priority, sorted by timestamp. It took an uncomfortable review of our own response times to notice that flags from users with no assigned therapist — the people with the least existing support — were sitting in the queue longer than flags from users who already had a therapist checking in on them regularly. We rebuilt the queue to weight for exactly the opposite: less existing support means higher priority, not lower.

False positives, and why we accepted them

A keyword system flags things a more sophisticated model might correctly ignore — someone journaling about a difficult film, a metaphor, an old memory raised in a coping exercise. We accepted a higher false-positive rate on purpose. A reviewer spending an extra minute confirming a flag was unnecessary is a cost we're willing to pay every time, against the alternative of a system tuned to minimize interruptions that misses someone it shouldn't have.

Crisis Resources as furniture, not a popup

Crisis Resources live permanently in the dashboard navigation, not behind a modal that appears after a risky answer on an assessment. We debated this. A triggered popup feels more responsive to the moment. But it also implies the resource is only relevant if you've been flagged as high-risk, which is exactly the message we didn't want to send. Support should be reachable by anyone, on an ordinary Tuesday, without having to justify needing it.

988 and knowing our own limits

Nowhere in this system does YouMindo present itself as equipped to manage an active emergency. Crisis Resources point directly to the 988 Suicide & Crisis Lifeline and to emergency services, clearly and without any interstitial friction, because those are the services actually built and staffed for that moment. Our job is everything around that moment — noticing early, making a plan in advance, connecting someone to a person who can help — not replacing what 988 or emergency responders do.

What we still don't solve

We don't catch everything. A keyword system misses people who don't use flagged language, and a plan written on a calm day doesn't guarantee it gets used on a hard one. We know this, and we'd rather say it plainly than overstate what the product does. What we can do is make sure the systems around a hard moment are honest, human-reviewed, and quick — and that when someone reaches for help inside YouMindo, something real is on the other end.