-
-
Problem
-
Architecture
Inspiration
In 2021, during Malaysia's flood relief efforts, I coordinated donations for a small relief push — connecting people who wanted to give with families who'd lost almost everything. The work was never short on generosity. It was short on coordination. I'd wait for word on what was actually needed, chase donors for what they actually had on hand, take stock by hand, plug the gaps by buying whatever was missing, and start the loop again the next day. It took a small army of volunteers just to keep that cycle turning — not because people weren't willing to help, but because nobody could answer, in real time, the one question that decides whether a donation is actually useful: does this match what's needed, right now?
That question is the whole problem. Donations don't fail because people aren't generous — they fail because nobody has the hours to check the one fact that decides whether an item can actually be used: the right size, the right age group, proof it's safe. Today, that's still a human's job, done by phone and by spreadsheet — by someone like the volunteer coordinator I was in 2021. Organisations like Good360, The Lost Food Project, and Kechara Soup Kitchen do this exact job every day, at a scale far beyond what a handful of volunteers can sustain by hand. We built The Missing Call to be that coordinator — automatically.
What it does
The Missing Call is a generic donation-matching and coordination engine. Donors describe what they have; recipients describe what they need. When a match is blocked by one missing fact — is it packed, what size, is the device wiped — an AI agent places a scoped, consented phone call to resolve exactly that fact. Only once the fact is confirmed does the engine release a match. A completed call never automatically certifies a claim: the system tracks a verification level for every fact, from donor-reported through document-supported to physically inspected, and it will not allocate against a fact that hasn't cleared the bar the recipient actually requires.
The matching engine itself is category-agnostic — school supplies, clothing, electronics, and more are configured as data, not code, so adding a new kind of donation never touches the solver.
How we built it
The product is a Next.js/TypeScript web app built around a lexicographic multi-objective matching engine: instead of one hidden score, it optimises through explicit, ordered stages — maximise recipients with a minimum viable allocation, then complete bundles, then priority-weighted demand, then preference satisfaction, then transport efficiency, then unmatched surplus. Every allocation is explainable back to the exact stage and constraint that produced it.
Category behaviour — required attributes, bundle recipes, review policies — lives in configuration, not in the solver, so an operator can add a new donation category from an admin screen without a code change. Call handling runs in a safety-first fixture mode by default, with phone numbers masked, credentials kept server-side, and every call requiring explicit authorisation before it's placed. A parallel FastAPI/Postgres service exists for production-scale deployment beyond the in-memory demo store.
We validated the full loop end to end against our own school-reopening demo dataset: a cold run against real donation and need data produced zero usable bundles. After three authorised calls resolved the missing facts, the same data produced 20 complete kits across two schools — while correctly still refusing to allocate laptops that lacked documented proof of data sanitisation.
Challenges we ran into
The hardest design decision was making the trust boundary explicit rather than convenient. A completed phone call is genuinely useful information, but it isn't proof, and it would have been easy to let a completed call quietly upgrade a fact's verification level. We kept those two things separate, even when it meant the system deliberately withholds a match a human operator might have been comfortable making informally.
The second was resisting a category-specific solver. It would have been faster to hardcode school-kit logic for the demo. Instead we built the attribute and bundle-recipe system generically, which took longer up front but means the same engine handles clothing or electronics without new code.
What we learned
The coordination gap is bigger than any single crisis. We started from a flood-relief moment, but the same gap shows up every week at ordinary donation drives — and it's already someone's full-time job at organisations like Good360 and Kechara Soup Kitchen. The product that matters isn't a disaster-response tool; it's infrastructure for the coordinator role that already exists.
What's next
Piloting with a redistribution coordinator — not a single donor or a single recipient org — since that's the role our own architecture is actually built for: one operator running the match across many donor and recipient organisations at once.
Log in or sign up for Devpost to join the conversation.