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=<account>.<region>
SNOWFLAKE_USERNAME=<username>
SNOWFLAKE_PASSWORD=<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 fallback is first-class, not an afterthought.
Best Use of Google AI — Gemini auto-categorization
Gemini analyzes every posted need (description and/or photo) to propose category, item type, quantity, and urgency. A local keyword-and-regex engine (lib/auto-tag.ts) provides identical functionality when Gemini isn't configured, so the platform never depends on a live API key to function. AI assists the steward — it does not replace the steward's judgment.
What I'd build next
-
Solana confirmation ledger — writing each verified handoff on-chain so badge counts are cryptographically auditable, not just database rows. The
ConfirmationRecordmodel already has anon_chain_reffield waiting. - ElevenLabs voice input — letting stewards speak updates instead of typing, with auto-narrated Case Page timelines in multiple languages for low-literacy accessibility.
- Duplicate detection — Gemini visual-similarity + area matching at Case Page creation, to prevent two stewards unknowingly opening pages for the same person.
- Stewardship transfer — a formal flow for community members to take over inactive Case Pages after a defined inactivity window.
- Real geospatial infrastructure — replacing manual neighborhood tags with location-aware matching and proximity-based feed prioritization.
The point
Someone posts a need. Someone else offers what they can. The community connects them. The handoff happens. The steward verifies it. The contribution becomes part of a trusted record.
Not everyone can donate money. But almost everyone has something they can give — a bag of rice, a spare cane, an afternoon.
NeedFeed turns those small acts into a connected, accountable community. No cash to divert. No vulnerable people to tag. No badges to fake. Just rice, sweaters, wheelchairs, and the receipts to prove they arrived.
NeedReel
Hyperlocal in-kind giving. Post a need, anyone can pledge a piece of it into an open pool a steward confirms the handoff, and the giver earns a verifiable badge — no money, no tagging of vulnerable people.
Product thinking lives in plan.md and problems.md (at repo root, ..).
Run it
npm install
npm run dev # http://localhost:3000
The app works with zero API keys. Local auto-tagging stands in for Google AI and the Snowflake dashboard falls back to computing the same metrics locally.
Demo script (2–3 min)
-
Reel (
/) — filter by category/area, open a need. -
Case Page (
/cases/c-arjun) — multi-entry timeline, recorded-consent badge, steward tools. - Pledge — on a need card, pledge a portion → “Mark handed off”.
-
Confirm — on the Case Page, steward tools → “Confirm received” → giver badge increments (see
/toolbar is per-user; badge lives instore.json). - …
👥 The Team
Our team came together for the International Charity Day DEV Challenge to build NeedFeed:
- @pritam_patra_429a25dedae6 (Lead Developer)
- @t-rexbytes (Collaborator)
Built with Next.js 15 · React 19 · Snowflake Data Cloud · Google Gemini AI · Leaflet · TypeScript
Top comments (2)
well this was a interesting project to work on, as we have tried to imitate the vibe of having a feed like environment for the problems near our own areas, we also kept an eye on to let the users to make communities and also post for the needy peoples as follows.
Our main motto was to raise awareness that, anyone could help the people of their local society not just by money, also with their free time and skills. As this is the challenge for international charity day ❤️.
It takes time but at last we built it