Web Platform & Member Portal

Overview

When crisis strikes, Ohio responds. Since 1996, the Ohio Crisis Response Team has been the small non-profit that arrives in the moments, days, and weeks after a community is shattered. A natural disaster. An act of mass violence. A tragic accident. Their volunteer responders provide immediate, on-scene support to people in the hardest hours of their lives.

Thirty years and more than 400 deployments later, the team needed digital infrastructure that could keep up with the work without becoming the work.

That's what I'm helping them build.

Responders before operators

OCRT runs on a very small volunteer staff and a roster of community volunteers, most of them clinicians, first responders, and peer counselors. They are responders before they are computer operators. Every minute one of them spends fighting a tool is a minute they are not with the people they showed up for.

So the brief wrote itself. What does this team need their digital home to do, and how do I make it disappear into the work? That question shaped every decision that followed.

The public site

OhioCrisisResponseTeam.org is live. It is the front door for the people who actually call OCRT in: law enforcement and emergency-management leaders, school superintendents, local-government officials with the authority to formally request a deployment.

For them, the site has one job. Answer the questions a public-safety leader has at two in the morning, before they pick up the phone. What does this team do. Who are these responders. How do I invite them in. Plain language, no charity-speak, no jargon. The writing speaks to a decision-maker in a hard moment, not to a donor at a gala. The site also carries the team's outreach, so funders can see the work and a wavering partner can find their answers without a meeting.

The harder problem was everyone else the site has to reach. When OCRT deploys, the affected community is whoever was there, and in Ohio that is rarely one language and one background. So the site is built to meet people where a crisis finds them. It ships in eleven languages: Arabic, English, Spanish, French, Hindi, Russian, Somali, Swahili, Turkish, Vietnamese, and Simplified Chinese. That list is not decorative. It maps onto the immigrant and refugee communities who actually live in Ohio's cities, the Somali families in Columbus among them. The framework is built and running. The translations themselves are waiting on native-speaker validation before I will call them done, because a message meant to reach someone on their worst day, delivered in machine-translated approximations, does more harm than no translation at all. I want receipts on every locale before it carries weight.

Trauma-informed design shapes the tone as much as the structure. A person reaching this site may have just lived through the worst day of their life. The content does not perform urgency or sentiment. It states what help exists and how to reach it, then it gets out of the way.

The quiet craft underneath

None of that should be visible to the people using it. The site runs as a Nuxt 4 application in a TypeScript monorepo, with the public site and the member portal sharing one codebase and one deployment pipeline. The multilingual system is wired through the framework rather than bolted onto the side, so correcting or adding a language is a content change, not an engineering project the team has to call me to run.

I am not going to pretend any of this is exotic. It is current, well-supported, deliberately boring technology, chosen precisely because it is. A volunteer-run non-profit cannot carry a clever stack that needs a specialist on retainer. The craft here is in what the team never has to think about: the site loads fast, holds up under the traffic spike that follows a public incident, and does not break when nobody is watching it.

The member portal

The member portal is the second front, and it is still in active build-out. This is where active responders will manage their certifications, training records, deployment availability, and the paperwork that follows a deployment.

The design priority is the same one from the start, pointed inward. Every screen reads in a glance. Every action takes the fewest clicks I can get it down to. The system absorbs the mundane administrative work, so a volunteer who just got home from a deployment can close out their record in a few minutes and go be a person again. It is not live yet, and I am not going to dress up a work in progress as a finished thing. When it ships, it should feel like it was always there.

My role

I am wearing two hats. The first is advisor: helping a small non-profit get its digital posture current without drowning the people who run it. Choosing tools they can sustain after I am gone. Making each technology decision earn its keep against the mission, and saying no to the ones that don't.

The second is builder: a public site they are proud to point a partner at, and a portal their responders will actually want to open.

The work I want more of looks like this one. An organization doing something that matters, run by people stretched thin, who need the infrastructure to simply hold so they can do the part only humans can do.

Status

The public site is live at ohiocrisisresponseteam.org, shipping in eleven languages with native-speaker validation underway. The member portal is in active build-out.

References

• Public site: ohiocrisisresponseteam.org