BenefitPath

💡 Inspiration

Billions of dollars in U.S. public benefits go unclaimed every year — not because people don't qualify, but because the system is a maze. Dozens of programs (SNAP, Medicaid, WIC, LIHEAP, housing assistance…) each have their own rules, forms, and agencies. People who most need help are the least likely to have the time or expertise to navigate it. We wanted to build a calm, plain-language front door that helps someone discover what they might qualify for in a few minutes — without pretending to be the government.

🧭 What it does

BenefitPath is a guided, chatbot-style intake. It asks a short set of questions (age, state, employment, household income, family size, student and disability status), then asks one adaptive follow-up chosen by explainable rules from the answers so far. It then uses an LLM to surface the public benefit programs a person may qualify for, along with the reasoning, the documents they'll likely need, and concrete next steps — every result links to official .gov pages and a human referral (211, Benefits.gov, their state agency).

Crucially, it never guarantees eligibility. Only the responsible agency can decide. BenefitPath is an informational signpost, not an adjudicator.

🛠️ How we built it

• Backend: Node.js 20 + Express 5, with Helmet for a strict Content-Security-Policy.
• AI: the Groq API (llama-3.3-70b-versatile) via Groq's OpenAI-compatible endpoint, called server-side only so the key is never exposed to the browser.
• Persistence: MongoDB Atlas (Mongoose) stores each session's profile, full chat history, and analysis result.
• Frontend: accessible, responsive vanilla HTML/CSS/JavaScript — no framework, fast to load.
• Adaptive follow-up: instead of asking the LLM what to ask next, a small rules engine picks the most informative follow-up (work history, pregnancy / young child, senior benefits, or housing cost burden) so the choice is transparent and explainable.

One of those rules — flagging a likely housing cost burden — uses the standard HUD threshold of spending more than 30% of income on housing:

$$ \text{cost burden} = \frac{\text{monthly housing cost}}{\text{monthly household income}} > 0.30 $$

• Deployment: pushed to GitHub and deployed on Render as a Node web service, with secrets injected as environment variables.

🧱 Challenges we ran into

• Keeping the AI honest. LLMs love to say "you qualify!" We layered guardrails: a system prompt that forbids guaranteeing language, a server-side language guard that rewrites accidental certainty phrases, and a human-in-the-loop referral block injected server-side into every response so the model literally cannot omit it.
• Adaptive but explainable. We deliberately kept the follow-up selection as deterministic rules rather than another model call, so we can always explain why a question was asked.
• Deployment gotchas. Getting the start command and process.env.PORT binding right on Render, and opening MongoDB Atlas network access for a host with no fixed outbound IP, took some debugging.

📚 What we learned

• Responsible-AI design is mostly systems design, not prompt wording — the strongest guarantees come from server-side code the model can't bypass.
• A little deterministic logic (the rules engine) makes an LLM product feel far more trustworthy and explainable.
• Real benefit eligibility is genuinely complex; the most valuable thing software can do here is reduce friction and route people to humans, not replace them.

🚀 What's next

• More programs and state-specific rules, with localization.
• Optional anonymous accounts, rate limiting, consent language, and a privacy review before handling real personal data at scale.
• Eligibility estimators (income thresholds per program) shown alongside the AI's reasoning.

Built With

• css3
• express.js
• github
• groq
• helmet.js
• html5
• javascript
• llama
• mongodb
• mongodb-atlas
• mongoose
• node.js
• render
• rest-api