NeedFeed 🤝 - Safe, In-Kind Mutual Aid Without Cash or Tagging

This is a submission for the Weekend Challenge: Generosity Edition. Prize categories: Best Use of Snowflake · Best Use of Google AI The problem I couldn't unsee Most charity tech solves the wrong problem. It makes it easier to move money - when the actual friction is moving things. It makes it easier to identify people in need - when the actual requirement is protecting them. It makes it easier to claim generosity - when the actual value is proving it. Three failure modes, and they all start before a single dollar changes hands: Cash is a liability, not a feature. When the need is "10 kg of rice" but the mechanism is "send ₹500," you've introduced an unnecessary conversion step - and with it every failure mode: fee skimming, diversion, a middleman buying the wrong thing entirely. Tagging is surveillance in a helpful mask. "Tag someone who needs this!" sounds generous. It publicly identifies a vulnerable person to a stranger, with no consent, no accountability, and no recourse. Self-reported badges are meaningless. Most platforms award "generous donor" status when someone says they gave. No one checks. The badge becomes a participation trophy, not a trust signal. NeedFeed exists because charity does not have to mean money - and almost everyone has something they can give. What I Built NeedFeed is a hyperlocal, in-kind mutual aid platform. Neighbors coordinate real, physical help - food, clothing, medical supplies, school materials, volunteer time - without ever touching cash, without publicly tagging vulnerable people, and without asking anyone to just trust the process. The unit of generosity is a physical item: a warm sweater, a walking cane, a bag of rice. The unit of trust is a verified handoff - not a payment receipt, not a checkbox. Four hard rules - in the data model, not the guidelines 1. Strictly in-kind, zero cash, ever. Food, clothing, medicine, mobility aids, school supplies, shelter materials, hygiene kits, and volunteer time only. There is no "donate cash" button, and there never will be. 2. Open pledge pool, no direct tagging. A posted need enters a public pledge pool. Any neighbor can pledge to fulfill it, but no one gets a private link, a DM, or a direct connection to the beneficiary. 3. Steward representation, with recorded consent. People who can't represent themselves online - no phone, no literacy, no connectivity - are represented by a verified local steward who opens a persistent Case Page on their behalf, only after a recorded verbal consent clip, not a checkbox. 4. Two-party verification cycle. A giver pledges, marks the item "Handed Off." Only after the steward independently confirms receipt with the beneficiary does the giver earn their Honor Badge. A mismatch is flagged and auditable. The badge means something because it costs something to earn. Demo Run locally - zero API keys required: git clone https://github.com/Pritam-mb/charity.git cd charity npm install npm run dev # → http://localhost:3000 The local auto-tagger and local metric engine stand in for Gemini and Snowflake respectively. To connect the real services, add keys to .env.local : # Snowflake Data Cloud SNOWFLAKE_ACCOUNT= . SNOWFLAKE_USERNAME= SNOWFLAKE_PASSWORD= SNOWFLAKE_DATABASE=CHARITY SNOWFLAKE_SCHEMA=PUBLIC SNOWFLAKE_WAREHOUSE=COMPUTE_WH # Google Gemini AI GOOGLE_AI_API_KEY=AIzaSy... GOOGLE_AI_MODEL=gemini-1.5-flash Delete data/store.json and restart the dev server to reseed with fresh, realistic demo data. GitHub → Pritam-mb/charity The walkthrough The feed The home feed is designed for Gen Z: visual, fast, and community-driven. It's a dark-mode, Reddit-style three-column layout - a collapsible left sidebar for navigation, a center feed with segmented sorting (New / Hot / Top Urgent) and category/neighborhood filters, and a right rail with a Local Area Explorer and community rules. You can browse new, hot, or urgent needs, filter by category and neighborhood, and see exactly what is needed - with a real image, urgency flair, and steward-beneficiary attribution ("Posted by Rashid on behalf of Arjun"). Every need card has a four-action bar: Support, Comments, Share, and Pledge Help. Opening a need Open a need and you get the full context - item, urgency, quantity, neighborhood, and the Case Page it belongs to. A verified local handoff point appears on the Leaflet map, so help stays simple and local. No stranger-to-stranger coordinates. No private DMs. Making a pledge Choose Pledge Help, select what you can provide, and complete the handoff. But a pledge is not impact. You mark it Handed Off. Then the verified steward confirms delivery with the beneficiary. Only when both sides confirm does the system record a verified contribution and award the Honor Badge. That two-step is not a formality - it's the whole point. Posting a need Posting only requires a plain-language caption and an optional photo or video. Gemini AI analyzes the description and proposes category, item type, quantity, and urgency - all fully editable before publishing. AI proposes; a human confirms. Nothing auto-publishes. When Gemini isn't configured, a local keyword-and-regex inference engine (lib/auto-tag.ts ) handles the same job. The workflow never breaks because of a missing API key. Case Pages Case Pages (/cases/[id] ) are dedicated, persistent profiles for recurring or high-vulnerability beneficiaries. Instead of isolated posts, a Case Page becomes a living record of the community helping one person over time. Each page has: - A letter avatar and alias name (never a legal name) - A verified-consent badge - An append-only steward update timeline with photo evidence - All associated needs with their fulfillment status - A defined handoff location - a known local anchor point, not a stranger's address The community extends beyond individual needs too - people can offer items, volunteer their time, connect with organisations, and follow cases they care about. Account settings define a person's platform role (volunteer, steward, NGO leader), primary neighborhood for anchor-point matching, and contact info - which is only ever shared with stewards at the point of a pledge or handoff, never made public. Achievements Confirmed, fulfilled needs become a quiet public record - not a leaderboard of who gave the most, but a feed of what actually changed for someone, with a link back to their Case Page. Verified contributions, not participation trophies. Snowflake HQ - the transparency layer Then comes Snowflake HQ - what I call the GlassPocket layer, because every transaction is visible through the glass. A one-click POST /api/sync pushes the entire local transactional state to Snowflake. Dashboard metrics are then computed via Snowflake SQL when available, or locally from store.json when not - the platform is always operational either way. Snowflake surfaces: - Which neighborhoods have the most unfulfilled needs - Which categories are chronically undersupplied - Which Case Pages are going stale (steward abandonment detection) - Whether badge counts actually correspond to real confirmed handoffs - Which shared needs convert into pledges and which don't Top Givers are ranked by confirmed handoffs - not pledges. That single distinction is the difference between a leaderboard and an accountability record. The stack | Layer | Tech | Why | |---|---|---| | Framework | Next.js 15 (App Router), React 19 | Server Components for the heavy lifting, Client Components for interactive hubs | | Language | TypeScript (strict mode) | 100% type safety across every API route and component | | Styling | Vanilla CSS, custom design system | Reddit dark theme, glassmorphism, responsive grids - no framework overhead | | Data | Local JSON store (data/store.json ) | Atomically managed via lib/store.ts , auto-seeded on first run | | Intelligence | Google Gemini AI | Auto-categorization, item extraction, urgency scoring on upload | | Analytics | Snowflake Data Cloud | Relational telemetry with automated local fallback | | Mapping | Leaflet + OpenStreetMap | Hyperlocal anchor point visualization | Repo structure: app/ Next.js App Router - pages, layouts, API routes components/ Feed, need cards, pledge pool, steward tools, forms, dashboard widgets lib/ Types, store, seed data, Gemini client, Snowflake queries, auto-tagger data/ store.json (auto-generated, gitignored) scripts/ Snowflake diagnostics and connectivity tests public/images/ Photorealistic need imagery Worth reading: plan.md (product thesis), problems.md (every risk identified and how it's mitigated), lib/store.ts (the two-party verification cycle), lib/snowflake.ts (dual-engine telemetry with automatic fallback). Safety decisions I'm proud of Alias names, not legal names. Case Pages use pseudonyms and broad neighborhood tags - never exact addresses, never legal identity. No solo stewardship. One person alone speaking for another is exactly the risk the platform exists to prevent. The system requires co-stewardship. Consent isn't a checkbox. Verbal recorded consent is a structural requirement - a field in the data model, not a terms-of-service paragraph. Anchor points over direct meetups. Handoffs route through a known local location (a shop, a community hub) rather than a stranger-to-stranger connection. Staleness detection. Snowflake flags Case Pages with no recent updates. An abandoned page that still looks active is worse than no page at all. Editable AI tags. Gemini proposes; the steward confirms. No auto-publish, no blind trust in classification. Prize categories Best Use of Snowflake - GlassPocket accountability layer Snowflake is the transparency backbone. It powers the institutional dashboard (unfulfilled needs by category/area, urgency distribution, steward staleness detection, confirmed-handoffs-only leaderboard) with a dual-engine design that falls back to local computation with zero downtime if Snowflake is unreachable. Key design choice: analytics that fail silently are worse than no analytics at all - so the f