标签：#devchallenge

This is a submission for Weekend Challenge: Generosity Edition What I Built The money exists. A small NGO just cannot find it. That is what a generosity problem looks like at the small end. The giving has already happened — foundations with open, rolling, unclaimed programmes, sitting there — and it is spread across a few thousand pages nobody has time to read. After the 2025–26 collapse of USAID funding, organisations that had one funder now need six, and the people doing that searching are the same people running the programme: a director who is also the grant writer, working evenings. Generosity is not the scarce thing here. Attention is. So an AI grant finder is an obvious idea. It is also a dangerous one, because the failure mode is not "unhelpful." A three-person NGO that spends a week writing an application against a deadline that never existed has lost a week it cannot get back, and it will not find out until it submits. The tool would have taken the one thing that was actually scarce. FundFinderAI is the response, in one sentence: it searches the live web for currently open grants that fit your NGO, and then it refuses to trust its own model about any of them. Every application URL Gemini produces is independently fetched before you see it, and the card tells you what happened when we tried. The interesting part is not that it searches. It is everything the app does to establish that the search actually happened and that the result actually exists. Demo Live: fundfinder-ai.vercel.app — describe an NGO, get grants, open a drafted Letter of Inquiry. Give it 30–120 seconds. It is running ten to thirty real Google searches and then fetching every URL that comes back, and the page shows you the clock while it does. Paste this in if you would rather not invent an NGO: NGO name: Kisumu STEM Girls Collective Location: Kisumu, Kenya Mission: We run after-school robotics and coding clubs for girls aged 12-17 in Kisumu, Kenya, and train their teachers to keep the club

This is a submission for Weekend Challenge: Generosity Edition TL;DR Happen to Have? is for somebody who needs one answer and still has something useful to give: answer a stranger before asking your own question. An answer fans out to four Gemini calls—processing, crisis, illegal or dangerous content, relevance. A question gets three, since relevance has nothing to compare it with. Only processed text is ever published. The original recording exists for the length of one request and is never stored. Halfway through, the measurement behind my strictest architectural rule turned out to be confounded, and the rule came out of the constitution. Live at happentohave.anchildress1.dev , with five feature specs, the measured guardrail results, and the full implementation in the repo. Target category: Best Use of Google AI. What I Built Nobody Called It Anything 🪧 Going to church every Sunday was a requirement while I was growing up, and the ladies there had a group called the Busy Bees who would do literally anything that needed doing for somebody in need. So when this challenge asked me to "build something in the spirit of generosity," that's what I thought about first. The problem was translating that to a scale that actually works. The Busy Bees worked because everybody already knew everybody, and that is not true of an app accessible from anywhere. I spent the next hour trying to brand the thing, running back through everything I could remember about how generosity has actually shown up in my life, and it eventually hit me that there's no word for any of it—because it's so normal where I live. A complete stranger is stranded with a flat tire, and you spend an hour on the shoulder helping, just because you happen to have a jack in the truck bed. It's not out of the ordinary enough to need a name. So I built Happen to Have? on the idea that if you happen to have a solution, you share it. A donation tracker would have been simpler. It also would have left giving optional.

This is a submission for Weekend Challenge: Generosity Edition What I Built Every charity app I've used starts with the same question: how much money can you give. If the answer is not much, you feel a bit guilty and close the tab. That's the actual problem I wanted to solve. Most people don't skip giving because they're selfish, they skip it because the ask never fits what they actually have. Two hundred rupees feels too small to matter. An hour on a Saturday doesn't feel like "volunteering." An old laptop just sits in a drawer. Spare flips the question. Instead of asking what you can donate, it asks what you have spare right now, whatever that is: some cash, a free evening, a skill, a language you speak, an object you don't use, access to something like a car or a rooftop. You type it in plain language (any language, any mix, doesn't matter), and Spare reflects it back to you as a little inventory, then gives you three specific things you can actually do with it this week. Not "go volunteer somewhere," but the actual organization, the actual first step, and a message already drafted for you to send. The thing I cared about most while building this: most tools like this stop at "here's a place near you" and leave you to figure out the rest. Spare tries to close that last gap, because that's usually where good intentions die. I also didn't want to just trust whatever an AI tells me is a real charity. So every result comes with a label telling you exactly how sure Spare is: confirmed live through search, hand checked by me beforehand, or "search this yourself" if neither of those worked out. I'd rather show you three honest results than five made up ones. Demo Live app: https://spareapp.ai.studio Try the demo personas on the first screen if you don't want to type anything, they'll walk you through the whole flow in a few taps. Code GitHub repo: https://github.com/dhruvvvgg/spare How I Built It I built this entirely on my phone using Google AI Studio, so the whole thi

This is a submission for the Weekend Challenge: Generosity Edition Don't Just Ask AI. Give the Answer Back. AI is a real force multiplier for software development. It's also the ideal companion for solving technical problems fast. But all that knowledge — we keep it to ourselves. Or rather, we lose it. The story always stops there. Question → answer → problem solved — and the conversation sinks into the chat history, gone. Then someone else hits the exact same wall. Same cycle: question → answer → problem solved — and the conversation sinks into the chat history, gone. That's the problem. Not that AI can't solve the same issue twice — it's that a working solution already exists somewhere: someone already investigated, tested, found the fix, and had a conversation detailed enough to explain it properly. Why should that knowledge evaporate the moment the session ends? Why keep asking the same question over and over — burning electricity, water, and time that's already been spent — instead of recycling that raw material? That's the idea behind Shared Knowledge MCP . What I Built Shared Knowledge is an MCP server that turns a solution from an AI conversation into a proposed Markdown article, then into a GitHub Pull Request submitted for human review. Once merged, the contribution is published to a documentation site and gets an audio version generated with ElevenLabs. The project turns a solved problem into a reusable piece of community knowledge — but only when the user makes the explicit decision to share it. The conversation itself stays strictly private. The MCP server extracts only the relevant solution, structures it as a standalone English Markdown article, validates it, and opens a Pull Request on GitHub. Nothing gets published automatically. A human reviews the contribution and decides whether it belongs in the shared knowledge base. Only once the PR is merged does the article land on the public documentation site, which in turn kicks off its audio version. The

I spent Friday night staring at a mock municipal utility shutoff notice. The text was dense. The language was punitive. The deadline was buried in a block of legal code on page two. Generosity usually shows up as time or money, and that kind of giving matters. I think it can also look like removing friction. Millions of vulnerable and non-native speaking families receive legalistic notices, like eviction warnings, utility shutoffs, medical bills, or benefit discontinuances, written in adversarial legalese. The emotional and cognitive weight is massive. These notices are dense no matter who is reading them. I still read some of them twice, and most people meet one while already having a hard week. What I Built I directed the build of Charitas Clew . It is an open-source, zero-judgment paperwork engine for public notices. Charitas Clew ingests overwhelming institutional notices and uses Google AI to decompress the legal gravity into plain-language clarity. Instead of a generic chat interface, it outputs a strict Action Protocol: The Actual Meaning : Demystified in plain, dignified language. Key Dates and Timelines : Pinpoints critical statutory deadlines and grace periods. Simple Next Steps : 2 to 3 actionable, reassuring instructions. Personal Speaking Script : A first-person script the user can read out loud when calling or visiting a clerk, caseworker, or counselor. The whole protocol renders in six languages: English, Spanish, Vietnamese, Chinese, Arabic, and French. A notice written in adversarial English comes back as plain language in the language spoken at that household's kitchen table. Charitas Clew joins the Clew Suite , my portfolio of civic tech tools focused on making complex systems more inspectable. Demo Live Production Instance: charitas-clew.web.app Firebase Hosting serves the frontend. Every AI call routes through the Express gateway on Cloud Run. Paste a notice or upload a photo of one, pick a language, and read the result. Code earlgreyhot1701D /

This is a submission for Weekend Challenge: Generosity Edition What I Built Community Solar Energy Bank is a platform that lets people and businesses with residential or commercial solar panels donate their surplus energy credits directly to low-income families in Brazil, through NGOs connected to each family's utility company. The idea: in Brazil's net-metering system, a solar panel owner who generates more than they use accumulates credits with their utility company, credits that often just sit there, underused. At the same time, low-income families served by the very same utility struggle with expensive electricity bills. This project connects the two without anyone touching real money, you're not buying anything, you're redirecting energy credit you already own. I wanted the project to be upfront about what's real and what's a demo. States and utility companies are real data (Light in RJ, Enel in SP/CE/GO, Cemig in MG, Equatorial in MA/PA/PI, Amazonas Energia in AM, Roraima Energia in RR, Neoenergia Pernambuco in PE), though coverage is deliberately partial, states without a registered utility show an honest empty state instead of fake data. NGOs are entirely fictional, and every card says so. No real money or energy transfer happens anywhere, the donation flow is a simulation end to end. Demo Live demo: https://solar-credit-exchange.vercel.app Flow: pick your state on the map, choose the utility company serving it, pick an NGO linked to that utility, enter how many kWh of surplus credit you want to donate, review an AI-generated checklist of what that utility typically requires, confirm, and see it reflected on the aggregated impact dashboard. Code claudiofilho87 / solar-credit-exchange Community Solar Energy Bank A demo platform that lets people and businesses donate their surplus solar energy credits directly to low-income families served by NGOs in Brazil. Built for the DEV Weekend Challenge: Generosity Edition hackathon. This is a hackathon demo. No real ut

Built for the DEV Weekend Challenge: Generosity Edition . Live: https://deadweight-jet.vercel.app Repo: https://github.com/AnubhavDash/DeadWeight The coat Someone in Rasuwa needs a coat. You have a coat. The arithmetic looks finished. It isn't. Between your hands and theirs sit an air waybill, a customs broker, a sorting line paid by the hour, a warehouse in a country whose warehouses are already full, and — often enough — an incinerator. Every one of those steps has a published rate. None of them appear on the box. This has a name in the humanitarian sector. They call the arrival of unrequested goods the second disaster , and they have been asking people to stop for forty years. The Logistics Cluster writes guidance about it. OCHA writes guidance about it. The IFRC's disaster-law reviews keep finding the same story: after Cyclone Pam, unsolicited donations sat in Vanuatu for twelve months. Airlink has put a number on the share of donated goods that is simply inappropriate for the response receiving it. And still the boxes come, because the impulse behind them is correct . Someone is cold and you have a coat. There is nothing wrong with that instinct. What's wrong is that nobody ever shows you the invoice. So I built the invoice. What it is Deadweight is a ledger for the gap between giving something and it arriving. You build a consignment on a manifest — winter jackets out of a wardrobe, bottled water by the litre, used shoes, soft toys, the medicine cabinet. You pick a route: air (days, and the only way into the cut-off districts), road over the Birgunj–Raxaul crossing (weeks), or sea and road (months, because Nepal is landlocked and the ocean stops at Kolkata). Then it prices the whole journey in USD, line by line, and every line opens: DECLARED VALUE $2,800.00 3 line items unusable used clothing -$1,615.00 15% of this class arrives usable SOURCE [ASSUMPTION] not needed or not appropriate -$540.00 40% of this class arrives usable SOURCE [ASSUMPTION] air freight D

This is a submission for Weekend Challenge: Generosity Edition What I Built When I read about the generosity theme, I immediately thought of integrating donations as a feature into an app or rather a game . But given the complexities of managing funds as well as the weekend time limit, I thought it was impossible. So then I researched platforms that could act as the middleman. One that would allow me to include and encourage donations without having the money go through me at all. That's when I found out about Pledge . The Pledge API is an API-first charitable giving platform designed specifically to let you embed global charity search and donation processing directly into your application without you having to hold, manage, or legally route the funds yourself. By acting as the intermediary through a donor-advised fund model (the Pledgeling Foundation), they handle the heavy compliance lifting—like verifying 501(c)(3) statuses, distributing money to nonprofits, and instantly automating tax-deductible receipts to the donors. Perfect! The Game The game is called Give Garden . It's a card game where you collect plants/trees as cards and strategically place them into your grid-like garden. You have cards with rarity ranging from common to legendary. Your placements of specific cards dictate how efficient your garden is at generating the game currency ( Blessings ). You water these plants to grow them and advance them to their next growth cycle up until the Fruit-Bearing stage. Then you harvest them and get the blessings. With these blessings you can buy Garden Decorations . These decorations help make your farm even more efficient. For example: The Geyser Fountain allows the two cards on either side of it to automatically be watered at a certain interval. You get free spins to have a chance at getting common cards. Each card has an associated type. And each type corresponds directly to a cause . For example: the Bear Bearer is a tree that bears literal bears as its frui

This is a submission for Weekend Challenge: Generosity Edition I wanted to build something for this challenge that didn't just talk about generosity but actually meant something, and felt beneficial. This tool can make it easier to go from "I have food to donate" to "I'm donating food". You take a picture of your pantry shelf, Gemini figures out what's actually in it, and the app turns that into a recipe for whoever receives it, a handwritten-style note of kindness, a real way to find a food bank near you, and a printable manifest to hand over at drop-off. What I Built PantryBridge is a small AI-powered toolkit for food donation. The flow is: 1. Scan your pantry. Upload a photo (or pick one of three one-click sample hauls if you don't have a pantry photo handy). Gemini does multimodal image analysis and returns a structured inventory: item names, categories, estimated quantities, dietary tags, urgency, and packaging condition. ( Sorry, GIPHY messed up my gif ) 2. Review the inventory. Everything shows up in a clean table with donation-readiness stats and a volunteer tip generated specifically for that haul. (If you need to, you can delete or add items!) 3. Find a real drop-off location. Enter your zip code and the app confirms your city/state (via a real geocoding lookup) and links you straight to Feeding America's actual food bank locator, so you're finding a real place to donate, not a mock one. 4. Get a recipe and a kindness note. Gemini writes a short recipe using mostly what you're donating, plus a genuinely warm, non-patronizing note to include with the box. 5. Print a donation manifest. A little printable card with the itemized contents and a mock barcode/QR for quick intake logging, with confetti when you pledge or print. Demo Try the Live App If you'd rather run it yourself: git clone https://github.com/780s/pantrybridge.git cd pantrybridge npm install npm run dev Drop a GEMINI_API_KEY into .env.local to hit the real Gemini API. Without one, every route qui

This is a submission for Weekend Challenge: Generosity Edition A donated washer can reach its next home with everything it needs — except the one thing a manufacturer manual cannot contain: what happened to this specific machine. The person who repaired it knows what was replaced, what was tested, how this unit should be started, and what was packed with it. The recipient usually does not. That gap is what HANDOFF carries. Give the appliance. Pass on the know-how. HANDOFF lets a refurbisher speak once, then turns that short, item-specific explanation into a bilingual voice-and-text handoff that stays with the appliance through one durable QR tag. The volunteer already has the knowledge in their head. Speaking for 20 seconds is cheaper and more natural than writing custom instructions, translating them, formatting them, and printing them. And the recipient should not need an account, an app, or an English-first interface just to understand the thing they were given. What I Built HANDOFF is an object-specific knowledge handoff for donated and refurbished equipment . A refurbisher records a short voice note about the actual appliance in front of them. HANDOFF then: cleans the real recording with ElevenLabs Voice Isolation creates an English ↔ Spanish voice handoff with ElevenLabs Dubbing v2 retrieves readable source and translated text persists the completed media gives the handoff one durable ID generates a printable QR tag that travels with the appliance What the recipient gets The recipient sees their language first. For the verified English → Spanish sample: Español — Recipient English — Original They can play the recipient-language voice, read the same handoff as text, and switch both audio and text back to the original together. If the audio cannot load, the readable handoff remains available. Scan. Listen or read. The technician workflow is deliberately small: record → clean + dub → attach No recipient profile. No manual translation step. No long form. Why this

This is a submission for Weekend Challenge: Generosity Edition What I Built Handover takes a plain description of what is going wrong inside a small charity and works out the role that would fix it. Not the role they asked for. The one they actually need. You type something like "our books are a mess, and we have missed two filing deadlines". It comes back with a full trustee role: the diagnosis, what the person would do, a deliberately short list of essential skills, an honest time commitment, and an advert you can paste straight into your newsletter. Then a volunteer pastes their CV, badly, and gets scored against every open role with a reason and an honest note on where the fit is thin. Why A couple of days ago I got an email saying Reach Volunteering is closing after 45 years. It genuinely hurt to read. Reach connected small UK charities with people who wanted to give them professional skills. Last year it placed 5,996 volunteers and trustees across 2,440 organisations. The people it placed contributed around £60 million in expertise. Ninety-six per cent of those organisations ran on under £1 million a year, and nearly half on under £50,000. It is not closing because the work stopped mattering. It is closing because funding for the infrastructure that helps small charities build capacity has dried up. Reach was the largest single source of trustees in the sector, and it is shutting at the peak of its impact. I volunteer as a digital navigator, which mostly means sitting with people who have been handed a system that assumes a confidence nobody ever gave them. You watch someone decide they are the problem, when the thing in front of them was just badly built. Reach existed to stop small charities from feeling like that about their own gaps, and now it is shutting down. I cannot rebuild 45 years of relationships in a weekend. So I picked the one piece of what Reach did that was pure expertise rather than headcount, and rebuilt that. The thing everyone gets wrong E

This is a submission for Weekend Challenge: Generosity Edition What I Built Karibu Give (Swahili for Welcome, Give ) is a USSD micro-donation platform that works on a kabambe phone(feature phone) with no data, no app, no account , just a phone number and a mobile-money PIN. Built for the International Day of Charity. Two things stop generosity from scaling in Kenya and across Africa: You need a smartphone to give. Most donation platforms are web-forms that assume Chrome, data bundles, and card rails. 40% of Kenyan adults still use feature phones. You need trust to give again. Donations disappear into a black box. Donors never see where 50 KES actually went. Karibu Give attacks both: Dial *384*6120# → 1. Donate → Pick a cause → Enter 50 → Confirm → M-Pesa STK prompt in 2 seconds. No internet, no app store, no signup. Session state is managed server-side via sessionId (Africa's Talking USSD callback at POST /ussd ). Real M-Pesa money movement — STK Push is triggered via my dedicated M-Pesa Service https://mpesa-service-3s2d.onrender.com/stkpush , which wraps Daraja API ( POST {phone:"2547...", amount} → CheckoutRequestID:"ws_CO_..." ). SQLite = source of truth, Snowflake = audit trail — every pending → completed/failed transition via POST /payment-callback ( Body.stkCallback.CheckoutRequestID Daraja shape + AT shape) is synced to DONATIONS_ANALYTICS in Snowflake with phone_hash = SHA256(phone).slice(0,16) , never raw PII. POST /admin/sync-snowflake batch-retries unsynced rows. Only 3 causes can be active at a time — admin ( /admin behind ADMIN_USER/PASSWORD Basic Auth) creates charities ( name, emoji, target_amount, description ), toggles active, edits, deletes (blocked if donations exist). USSD and landing page render only active causes , so the choice stays focused. The limit is enforced in SQLite ( countActive()<3 ) and in the UI ( Activate disables at 3/3). Two separate AI cards — not one bolted-on feature: ✨ Google AI Impact Summary (Gemini 1.5 Flash via @google/

This is a submission for Weekend Challenge: Generosity Edition What I Built GlassPocket — a tool that argues against the "overhead ratio," the dominant heuristic people use to judge charities (what % of donations go to "programs" vs. "overhead" like staff and infrastructure). That heuristic punishes exactly the investment that makes a charity effective, and it drives what nonprofit finance people call the "starvation cycle" — orgs under pressure to look lean end up under-staffed and under-resourced. You search a US 501(c)(3), and instead of a single overhead percentage, GlassPocket pulls their IRS Form 990 history (via ProPublica's Nonprofit Explorer API) and shows: Reserve months — how long the org could run on savings alone (low reserves = fragile, not "lean") Operating margin trends across up to 13 years of filings Staff-investment share — reframed as capacity, not waste Fundraising cost per dollar raised — a narrower, more honest efficiency metric than the classic ratio A peer-percentile chart against ~70 similar organizations in the same category A Gemini-written "myth-buster" card pairing each overhead-ratio assumption with what the numbers actually show A grounded chat box — ask follow-up questions about that specific org's finances, answered only from its own filing data Demo Live app: https://glasspocket.vercel.app/ Code hassan-2050 / glasspocket Overhead-ratio myth buster for US charities — Form 990 data via ProPublica, Gemini narrative generator GlassPocket — Overhead Myth Buster Live: glasspocket.vercel.app Category: Overall Winner + Best Use of Google AI (Gemini-powered narrative generator and chat) The Hook Most charity-rating tools reinforce the harmful "overhead ratio" myth. This contrarian tool argues against that dominant heuristic by reframing efficiency around outcomes and reserves. What It Does You search a US charity by name, and it pulls their IRS Form 990 history to generate a plain-English context-aware financial explainer that debunks the o

This is a submission for Weekend Challenge: Generosity Edition What I Built I grew up teaching myself to code in Pakistan on hardware that struggled to run modern dev tools. GPU hours on Lambda Labs cost $0.50–$3/hr. For a student trying to fine-tune a model or run a training job, that's not accessible. OpenRig is a peer-to-peer compute sharing platform. Donors register their idle hardware and run a lightweight agent binary. Recipients describe what they need in plain English, get matched to the best available rig via Google Gemini AI, and receive SSH access — time-limited, isolated, and without ever touching the donor's actual machine. No money changes hands. You're donating the thing that actually matters: compute. Demo Here is the video link Full flow: Donor registers their rig → copies agent token → runs the agent binary Recipient browses available hardware → submits a request explaining why they need it Gemini scores the request 1–10 for social/educational impact Donor sees the impact score and reason → clicks Approve Agent spins up an isolated Docker container with SSH, starts a bore tunnel, reports the public connection command back to the backend Recipient gets an SSH command and password in their dashboard → connects Donor can revoke access at any time → container and tunnel torn down automatically Code Here is the code: OpenRig How I Built It The stack Backend: Go + Fiber v3, SQLite (GORM) Frontend: SvelteKit + Tailwind CSS Auth: Supabase (JWT verified on the backend via JWKS) AI matching: Google Gemini 3.6 Flash via Google Gen AI Golang sdk Tunneling: bore (open source TCP tunnel) Isolation: Docker with hardened security flags The hardest problem: giving strangers SSH access without exposing the donor's IP The naive approach — direct SSH — exposes the donor's home IP to whoever connects. That's a non-starter. The solution is a relay architecture. The donor's agent binary runs on their machine and maintains a persistent poll loop against the backend. When

This is a submission for Weekend Challenge: Generosity Edition What I Built My late...

This is a submission for Weekend Challenge: Generosity Edition What I Built A donation ledger for a group too small to buy software. It is a Google Sheet, some Apps Script, and one public page a donor can open. The group I had in mind is the kind that exists on every street: a neighbourhood fund, a school parents' group, a committee that collects for winter coats. Money arrives over WhatsApp and leaves in cash, and somebody keeps it in a notebook. The arithmetic is not the hard part. The hard part arrives three months later when a donor asks where their money went, and answering needs the notebook, the person holding it, and an afternoon. Software for this exists and is priced for organisations with a finance team. So the ledger stays in a spreadsheet a volunteer already knows how to open, and the only thing added is what a spreadsheet cannot do alone: read messy human messages, refuse to trust its own reading , and publish the page that answers the question before it is asked. Demo The public page a donor opens → That page is the deployed page, byte for byte, with one line changed: where the Apps Script version writes <?= data ?> , the demo fetches the same JSON from a file so you can read it without a Google account. The JSON is produced by running the sample month through the same recordEntry() and publicView() the real script uses, so if the ledger rules change, the demo changes with them or the build fails. The sample month deliberately includes the things that go wrong: a receipt two volunteers forwarded, a donation typed with one zero too many and later corrected, and a reading the checks refused to trust. What the model read, and whether it was allowed to count → The ledger page shows the result. This one shows the part worth showing. Pick any of six real donation messages and it highlights the exact characters Gemini says it read the amount from, lists the three checks with their outcomes, and says why the row was posted or held. It is fed by a recorded run

This is a submission for Weekend Challenge: Generosity Edition What I Built Every...

One SQL statement over a VECTOR(768) column, 45,400 charities, and 2,917,459 real pairs used to check it. What the detector caught, and what it missed.

This is a submission for the DEV Weekend Challenge: Generosity Edition. What I...

This is a submission for Weekend Challenge: Generosity Edition What I Built Every year an enormous amount of aid money goes unclaimed. Not because it runs out, and not because nobody needs it, but because of something much stupider. The form is the wall. If you are blind, if you never learned to read well, or if you arrived last month and don't yet speak the language the form is printed in, the help you are entitled to is sitting behind a document you cannot fill in. You need a neighbour, a caseworker, or a volunteer to sit down with you. So you wait. Or you never apply at all. I wanted to see if the wall could just be removed. Amparo completes a real aid application entirely by talking . No reading. No typing. No form. It asks a few simple questions out loud, you answer in your own words in whatever language you speak, it reads back what it understood so you can catch mistakes, and it hands you a finished PDF to take to your local food bank. The part I care most about is that it accepts answers the way people actually give them. Nobody says "household size: four". They say: "We're me, my mum and two little kids." Amparo works out that there are 4 people in the household, 2 of them children , and moves on. It does the paperwork thinking so the person doesn't have to. You can also correct it at any time, about any field, however long ago you answered. Say "no, I said three, not four" and it fixes that value and carries on. That mattered more than I expected. A voice interface without a correction path is a trap, because you cannot see what it wrote down. Demo The moment worth watching: one messy spoken sentence, and three fields fill themselves in on the right. Code lluisestape-upc / Amparo Apply for aid entirely by talking, in your own language. Voice-first accessibility tool built with Gemini + ElevenLabs. Amparo Apply for aid entirely by talking, in your own language. Billions in aid go unclaimed every year, and one of the reasons is painfully simple: the form its