ReliefSignal
ReliefSignal is a local-first AI coordination workspace for disaster response teams. It converts incoming field updates, volunteer notes, and needs assessments into a live relief queue, a polished response brief, coordination checklists, outreach plans, and a 72-hour operational timeline.
Inspiration
Disaster response breaks down when critical updates arrive as a messy stream of WhatsApp notes, call summaries, volunteer messages, and half-complete assessments. Small teams and community responders often do not have a clean way to turn that flood of information into a shared action plan fast enough. ReliefSignal was built to give those teams a practical coordination surface that feels credible in the first minute, even when connectivity, staffing, and time are limited.
What it does
ReliefSignal takes rough field intake and restructures it into prioritized response signals. Each signal is scored for urgency, impact, and effort, assigned to a response sector, and dropped into a live coordination board with incoming, verified, mobilizing, and resolved lanes. The workspace also generates a response brief, a coordination checklist, and a partner outreach plan so local coordinators can brief volunteers, shelters, transport leads, clinics, and community radio without rewriting the same information repeatedly.
How we built it
The product is a static HTML, CSS, and JavaScript app with a deliberately local-first architecture. Signal scoring, prioritization, storage, exports, and the demo workspace all run in the browser. LocalStorage keeps the workspace persistent between sessions, and a service worker keeps the shell available offline after the first load. That keeps the coordination surface fast to open, easy to inspect, and reliable under the same operational pressure that inspired the project.
Challenges we ran into
The hardest tradeoff was making the experience feel polished and operational without introducing a backend or any external AI dependency. That meant building a believable triage model from deterministic heuristics, shaping the UI so it looks like a real command surface instead of a template, and keeping the export, board, and timeline synchronized from the same local state. We also had to make sure the product still reads clearly on mobile, because disaster coordination rarely happens on a single desktop screen.
Accomplishments that we're proud of
We turned a generic planning scaffold into a strong social-good product with a clear use case and a more distinctive visual identity. The workspace now feels like a real relief coordination desk, not just a generic task app. We are also proud that the response brief, checklist, outreach plan, board, and timeline all derive from the same local-first data model, which keeps the demo coherent and the architecture easy to inspect.
What we learned
We learned that social-good demos become much more convincing when the interface is anchored to a real operational rhythm. A good hackathon product is not only about the model or the idea. It is also about whether the workflow, language, and artifacts feel immediately useful to the people doing the work. We also reinforced that local-first design can be a real advantage for humanitarian scenarios where connectivity and deployment complexity are both constraints.
What's next
The next step is to connect ReliefSignal to real intake channels such as forms, SMS, and messaging groups while preserving the offline-first core. We would also add multi-incident workspaces, verified resource inventories, multilingual outbound messaging templates, role-based views for volunteer leaders, shelter coordinators, and health teams, and stronger agent handoffs for triage, outreach, and follow-up planning.
Built With
- css
- html
- javascript
- localstorage
- service-worker
Log in or sign up for Devpost to join the conversation.