Case Study · Community Tech · HMIS Application
SERVE513
The systems meant to help were getting in the way.
I built SERVE513 after seeing a consistent problem during outreach events: teams were working hard, but the systems around them made it harder to serve people well.
SERVE513 is a service coordination platform that helps volunteers manage clothing distribution, showers, food, and barber services in real time, reducing wait times and improving how events run from start to finish. What began as a solution for one organization is now evolving into a deployable SaaS platform for any organization serving unhoused communities.
Overview
The Problem
Outreach events were operating with paper systems and disconnected workflows. The issue wasn't a single broken step: it was how the entire system worked together.
Service delivery was hindered by:
- Reliance on manual, paper-based systems made tracking slow and error-prone
- Donation and resource needs were unclear, leading to mismatches between supply and demand
- Volunteers experienced high stress due to disorganized workflows and lack of visibility
As a result:
- Neighbors faced long wait times for essential services
- Many were forced to choose between critical needs
- Volunteer burnout reduced long-term engagement
Goal
Who we designed for
Design a system that improves operations, supports volunteers, and enhances the neighbor experience.
Operational teams
- Centralize data for visibility
- Identify demand patterns
- Enable better planning
Volunteers
- Simplify workflows
- Reduce on-shift stress
- Focus on neighbor interaction
Neighbors
- Reduce wait times
- Multiple services per visit
- No more tradeoffs
My Role
What I led
Led design and development from concept to deployment, driving product direction, prioritization, and iteration throughout.
- Defined workflows based on real-world service operations
- Prioritized high-impact features under constraints
- Translated operational challenges into scalable product solutions
- Used live data to guide iteration and decision-making
- Drove evolution from single-use system to SaaS-ready product
Approach
How I thought about it
Instead of building tools for individual tasks, I focused on service flow across the entire event. That meant:
- Capturing demand at intake, not just tracking inventory
- Designing for volunteers under pressure, not ideal conditions
- Creating real-time visibility across stations
- Shifting work earlier through prefill to reduce bottlenecks later
Key Product Decisions
How I decided
Build vs. Buy
Built a custom solution to support coordination of multiple simultaneous services, something existing tools could not handle.
MVP-First Approach
Launched a working prototype and tested in live events. Real environments revealed constraints faster than planning ever could.
Demand-Driven System Design
Prioritized capturing neighbor needs over traditional inventory tracking to understand demand more accurately.
The Solution
What we built
A system designed around real-world workflows, not theoretical ones. Four connected capabilities, each shaped by what actually happens on the ground.
01
Intake
Neighbor Intake System
Captures and structures neighbor needs at entry, before they wait in any line.
Volunteers tap the services each person needs. The system routes them across stations in parallel, and demand data flows directly into preparation for the next event.
02
Coordination
Queue Management
Organizes service flow so no neighbor waits in a line that doesn't need to exist.
Each station shows who's coming, who's being served, and where the bottlenecks are forming, so volunteers can shift effort in real time rather than guessing.
03
Visibility
Service Tracking Dashboard
Real-time visibility across every service running at once.
Coordinators see throughput, wait times, and resource use across clothing, showers, food, and barber services: one screen, no clipboards, no radio chatter.
04
Preparation
Prefill System
Moves work earlier, so the event itself runs faster.
Clothing orders are prepared in advance from intake demand, rather than assembled at the line. Throughput goes up; volunteer stress goes down.
Data in Action
How data is already driving impact
The system doesn't just track services: it directly informs how we prepare. Intake data from previous events now shapes how we stock the mobile clothing trailer.
Instead of guessing what to bring, we can see patterns in clothing sizes, item types, and demand by location. This allows us to reduce waste, bring the right items to each event, and prepare clothing orders in advance.
The product doesn't just improve event-day operations: it changes how we prepare before the event even begins.
The same data identifies where additional resources are needed most, whether that's expanding shower capacity, adding haircut stations, or adjusting staffing in specific areas.
Reflection · Featured Learning
The intake A/B test that changed how I think
When we tested the intake UI, the data and the practice disagreed. The "faster" design lost. The reason it lost is the lesson.
A · Dropdown
Objectively fasterA traditional select menu. Fewest taps, smallest screen footprint: the answer most efficiency-minded reviews would have predicted.
B · Tap-to-select
Won in practiceEach service is a tappable tile. More taps, larger footprint, but instantly readable under stress without explanation.
The best interface isn't always the most efficient one: it's the one people actually use consistently. Volunteers under pressure preferred tapping, and the adoption gap dwarfed the speed gap.
More Learnings
What I learned
Each insight came from prototype sessions with real volunteers during live events, not from theory or planning.
02
Low-fidelity testing is the best answer to feature pressure
Volunteers occasionally requested features that weren't clearly valuable. Rather than dismissing the request or building it outright, I introduced low-fidelity prototypes as a first step. Volunteers could test the idea themselves and often reached their own conclusions, reducing friction and keeping the product focused.
03
Flexible systems create room for unexpected scale
When we implemented the welcome desk workflow, the goal was to enforce sequential neighbor intake. What we discovered was that the underlying code was flexible enough to support two intake specialists running simultaneously, a capability we hadn't explicitly designed for, but that expanded throughput without any rework.
What's Next
The roadmap
SERVE513 is evolving from a single-use tool into a platform that can support multiple organizations.
Now
Standardize workflows
Adapt core workflows into a flexible, repeatable structure deployable across organizations.
Now
Configurable onboarding
Let any organization serving unhoused communities configure the platform around their service model.
Next
Predictive analytics
Use historical event data to forecast demand, so prep work can start earlier.
Future
AI coordinator support
An NLP agent translates reports into clear next steps, so anyone can act on the data without needing an analyst.
Started as a tool for one outreach event. Now becoming a platform for any organization serving unhoused communities.