MealLine

Inspiration

Food assistance should be as simple as asking for help. Technology, language, literacy, and disability barriers can make that first step difficult. Pantry staff also face the work of collecting household information, preparing suitable food, tracking inventory, and coordinating distribution.

MealLine brings these needs together: MealLine provides an accessible way to ask for assistance, while FEED turns those conversations into organized pantry workflows. Our goal is to make technology fade into the background so people can focus on receiving and providing food.

What it does

MealLine connects a conversational intake interface with food pantry management.

Callers answer one question at a time about household size, dietary requirements, cooking and refrigeration access, delivery availability, and accommodations. They can repeat questions, correct answers, and request human assistance. An accessible text interface provides another way to complete intake.

Once the caller confirms their information, MealLine creates a household request and proposes a shopping basket from available inventory. Suggested quantities scale with household size and stay within recorded stock. Dietary flags and kitchen requirements help filter unsuitable items.

Staff review and approve baskets, generate packing sheets, assign volunteers, schedule deliveries, and record completion. Marking a basket packed deducts inventory; completing delivery updates the linked request and basket.

The optional client phone workflow lets verified returning callers reuse household information, check delivery status, update their profile, request changes, or report missed deliveries. Consented SMS updates and callback reminders connect pantry activity back to the caller.

Dashboards and analytics show stock, requests, active deliveries, household patterns, and recorded service outcomes.

How we built it

We combined MealLine’s intake and case-management logic with FEED’s existing pantry management application.

MealLine uses Next.js, TypeScript, and PostgreSQL. A Python Pipecat service adds streaming speech through Twilio, with Deepgram for speech recognition, Cartesia for spoken responses, and Silero for voice activity detection. OpenAI structured extraction proposes fields from caller responses; the application validates those proposals and controls each conversation step. Deterministic interpretation provides a fallback when model extraction fails. Voice pipeline

The pantry workspace uses React and Vite, backed by Express, Prisma, and SQLite. We added household requests, baskets, clients, and delivery records to FEED, retaining its inventory, translation, reporting, and administration features.

A shared TypeScript package keeps dietary, equipment, and quantity rules consistent between backend matching and staff basket review. Matching rules

Challenges we ran into

The main engineering challenges were connecting conversational input to reliable operational actions:

• Handling interruptions, keypad input, repeated questions, and speech-service failures while preserving conversation state.

• Requiring explicit confirmation and validating model output before creating requests or changing household information.

• Making retries safe so repeated calls or commands preserve existing staff work and packing deducts stock once.

• Integrating different databases and data models while preserving inventory, transcripts, delivery links, and backup recovery.

• Protecting returning callers’ information, including households that share a phone number.

Language support also required different paths: English and Spanish use the streaming adapter, while Vietnamese follows the existing TwiML route.

Accomplishments that we're proud of

We connected a caller’s confirmed needs to a complete operational workflow: intake, proposed basket, staff review, packing, inventory deduction, and delivery tracking.

We also built safeguards for changing needs. Updates to dietary or kitchen information place active requests on a review hold, allowing staff to reassess the basket before dispatch. Profile revisions and call history make those changes traceable.

Our analytics distinguish requests, approvals, and completed deliveries. A household counts as served only after a recorded delivery completion, giving pantry staff a clearer view of outcomes.

What we learned

Accessibility requires several ways to participate: voice, keypad, text, repetition, readable confirmations, and human assistance. A simple interface still needs careful handling of uncertainty and interrupted conversations.

We learned to give AI a bounded role in interpreting language while keeping confirmation, authorization, inventory changes, and fulfillment decisions in application logic.

We also learned that useful automation depends on accurate pantry data. Dietary filters assist staff review; food labels, household notes, and current stock remain essential.

What's next for MealLine

Our next step is a pantry pilot with applicants, volunteers, and staff to evaluate the complete workflow.

We want to validate live call quality, review translations with fluent speakers, and test accessibility with people using assistive technology. Production work includes stable hosting, provider configuration, broader integration tests, and resolving inherited frontend type issues.

Beyond that, we want to improve food suitability and basket variety, add demand forecasting and replenishment recommendations, and measure whether Nourish reduces administrative work and improves successful fulfillment.

Built With

• cartesia
• deepgram
• express.js
• fastapi
• next.js
• node.js
• openai
• postgresql
• prisma
• puppeteer/chromium
• pydantic
• pytest
• python
• radix-ui
• react
• recharts
• silero-vad
• sqlite
• tailwind-css
• tanstack-query/table
• twilio-voice-and-verify
• typescript
• vite
• vitest
• zod