This is a submission for Weekend Challenge: Generosity Edition
What I Built
GiveTrack is a personal generosity tracker that helps you log donations, discover causes, and actually see your impact over time instead of giving once and forgetting about it.
The idea came from a simple frustration: most people who give to charity have no easy way to look back and understand their own generosity, how much, how often, to what causes. GiveTrack turns that invisible habit into something visible and motivating.
It includes:
- A dashboard with donation metrics and recent activity
- Searchable causes you can browse and support
Create-cause and demo-donation modals to log giving
A filterable donation history
- A "Generosity Chain" that visualizes your giving streak and impact over time
- Random kindness prompts to nudge small acts of generosity
- An AI Giving Assistant (powered by Google's Gemini API) that suggests giving ideas based on your activity
- Fully responsive, mobile-friendly UI
It's a local first prototype. All data lives in the browser via localStorage, so you can try the whole experience instantly with zero sign-up.
Demo
🔗 Live app: https://give-track-generosity-app--harshravaldj.replit.app/
(Note: no real payments are processed. This is a demo experience with seeded/demo data you can reset anytime.)
Code
harshravaldj
/
give-track-generosity-app
GiveTrack – a personal donation tracker built for the DEV Weekend Challenge: Generosity Edition. Log and visualize your charitable giving to stay accountable and see your impact over time.
How I Built It
Built entirely on Replit, using the Replit Agent to scaffold the app, iterate quickly, and manage version control (GitHub) directly from the workspace. It let me go from idea to a fully deployed, publicly testable app in a single weekend without leaving the browser.
GiveTrack is built as a pnpm monorepo:
- Frontend: React + TypeScript, with a custom visual system for the dashboard, modals, and Generosity Chain
- Backend: Express 5 API server
- Database: PostgreSQL with Drizzle ORM (schema-first, type-safe queries)
- Validation: Zod end-to-end
- API contracts: OpenAPI spec with Orval-generated hooks, so frontend and backend stay in sync automatically
- AI: Google's Gemini API, accessed via a Google AI Studio API key, called server-side to keep the key secure. It powers the "AI Giving Assistant," which suggests giving ideas based on activity. It has a friendly deterministic fallback if the provider is ever unavailable, so the app never breaks.
One deliberate decision: donations and cause data are demo/local-first (localStorage) rather than wired to a real payment processor. For a weekend build, this let me focus on the experience of tracking and reflecting on generosity, rather than payment infrastructure, while keeping the door open to add real giving flows later.
Prize Categories
Submitting for Best Use of Google AI. The AI Giving Assistant calls Google's Gemini API (via a Google AI Studio key) server-side to generate personalized giving suggestions.
Top comments (8)
nicely organized
Thanks so much for checking out GiveTrack! ❤️ Really appreciate your support! 🙌
This is a great take on the "generosity edition" theme, most donation trackers stop at the transaction, but the Generosity Chain and history view actually give people a reason to reflect on giving as an ongoing habit instead of a one-off. Smart call keeping it local-first for the weekend build too, since it let you focus on the reflection/UX side instead of getting bogged down in payment infra.
Curious how the AI Giving Assistant decides what to suggest. Is it just working off donation categories/frequency in localStorage, or does it factor in causes you've searched but haven't donated to yet? Also love that it has a deterministic fallback so the experience doesn't break if Gemini is down. Nice execution for a weekend timeline, especially with the full monorepo plus OpenAPI/Orval setup.
Thanks so much for this! Right now the assistant is mostly working off donation frequency and categories in localStorage, but factoring in causes you've searched without donating is a great idea, definitely adding that to the backlog. And yeah, the fallback was non-negotiable for me, didn't want a flaky API call to break the whole demo experience during judging.
Really like that you scoped this as local-first instead of trying to wire up real payments in a weekend. It's the right tradeoff for a challenge timeline, and it still lets people feel the full loop of logging, browsing causes, and seeing their history without any of the compliance overhead real donation processing would bring.
The random kindness prompts are a nice touch too, small nudges like that tend to matter more than big dashboards for actually changing behavior. Would be curious if you're planning to expand the AI assistant to suggest specific causes from your searchable list, rather than just general giving ideas. Solid weekend build overall.
Thank you, that's exactly the tradeoff I was going for. Skipping real payment rails let me spend the weekend on the actual reflection loop instead of compliance headaches. Expanding the AI assistant to recommend specific causes from the searchable list is a great next step, right now it's a bit more generic, so that's solid feedback for a v2.
The Generosity Chain is a clever hook, it turns giving into something you actually want to keep going, kind of like a streak but for kindness instead of habit-tracking guilt. And putting the AI suggestion layer server-side with a Gemini key was the right call for security, plus having a fallback means the demo never feels broken even if the API hiccups.
One thing I'd be curious about: any plans to eventually let this sync across devices, or does it stay local-first by design even post-challenge? Either way, solid scope for a weekend build with a full frontend/backend/DB split.
Appreciate that, glad the Chain lands the way I hoped! Cross-device sync is something I've thought about, probably via the Postgres/Drizzle backend that's already scaffolded in, just didn't want to add auth complexity into a weekend scope. It stayed local-first mainly to keep the challenge submission frictionless for anyone trying it out.