Inspiration During disasters, people often can’t reach help quickly—and even when they do, language barriers and overloaded dispatch lines delay critical response. We wanted to build a system that helps responders understand emergencies faster, no matter what language the caller speaks.
What it does CrisisBridge is a multilingual emergency intake and triage web app. A caller can start a voice session, speak naturally, and the system converts speech into structured incident data for dispatchers. It automatically:
Captures and commits live transcript segments Generates follow-up triage questions Extracts emergency type, severity, location context, and summary Pushes incidents into a dispatcher queue ranked by urgency Reads follow-up prompts aloud to guide callers calmly in real time How we built it We built a Next.js app with two interfaces:
User interface for voice intake, live transcript handling, and guided prompts Dispatcher interface for incident ranking, queue management, and response context Core integrations:
ElevenLabs for realtime speech capture/tokenized session handling Featherless API for incident extraction + follow-up question generation Client-side TTS playback to speak follow-up guidance from model output Robust API routes to isolate model calls, handle failures, and support real-time UI updates Challenges we ran into Model ID mismatches and provider configuration issues (model_not_found) Concurrency/rate-limit constraints (429s), especially with high-cost models Realtime UX edge cases: partial vs committed transcript timing Preventing duplicate processing and duplicate incident uploads Keeping the pipeline responsive while handling async model calls safely Accomplishments that we're proud of End-to-end realtime emergency workflow from voice input to dispatcher-ready incident Automatic transcript commit fallback for smoother realtime behavior Automatic follow-up question generation and incident upload pipeline Priority-based dispatcher queue with actionable summaries Practical resilience improvements around API errors and operational limits We also used OpenNote as our operations layer during development and demo prep. It helped us keep emergency-response workflows organized by storing triage playbooks, multilingual prompt templates, and follow-up question patterns in one shared place. As we tested CrisisBridge, we logged edge cases and transcript examples in OpenNote so the team could quickly refine extraction prompts and responder guidance. It also made handoffs smoother between team members by centralizing notes on API behavior, fallback plans, and demo flow, which was especially useful in a fast hackathon timeline.
What we learned Realtime AI systems need strong guardrails: dedupe, retries, serialization, and clear state boundaries “Working demo” quality depends as much on error handling as model quality Voice-first UX requires careful timing decisions around transcript commit behavior Prompt structure and strict schema validation dramatically improve extraction reliability What's next for CrisisBridge Add map geocoding + live marker visualization from extracted location data Add editable “review before dispatch” confirmation step Use ElevenLabs TTS voices for multilingual outbound guidance (instead of browser fallback) Add persistence, audit logs, and role-based auth for dispatcher operations Expand language coverage and improve model routing by incident complexity Build SMS/WhatsApp fallback channels for low-connectivity disaster scenarios GPT-5.3-Codex • 1x
Inspiration
What it does
How we built it
Challenges we ran into
Accomplishments that we're proud of
What we learned
What's next for CrisisBridge
Built With
- elevenlabs
- github
- node.js
- opennote
- react
- tailwind
- typescript
- vscode
Log in or sign up for Devpost to join the conversation.