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 (19)
This is such a solid weekend build! Reading through your "How I Built It" section left me with a lot of questions about how you actually figured all of this out.
Could you share more about your process? Specifically:
Any resources, videos, or a rough learning roadmap you'd recommend for getting from "can build a to-do app" to "can build something like GiveTrack" would be amazing. Thanks for sharing this in such detail!
Thanks so much for the thoughtful questions! I actually learned a lot of this while building GiveTrack, rather than knowing everything beforehand.
For the pnpm monorepo, I chose it mainly because I wanted the frontend and backend to live together and share types, configs, and generated API code. I had some basic understanding of monorepos before, but working on this project helped me understand the practical benefits much better.
For Drizzle + PostgreSQL, I relied heavily on the documentation and examples, and I also used Replit Agent to help scaffold parts of the setup. But I made a point of going through the generated code afterward to understand what was actually happening instead of treating it like a black box. That review process was probably one of the most useful parts of the experience.
OpenAPI + Orval was definitely one of the more advanced parts for me. I approached it step by step. First I understood what an API contract is, then how OpenAPI describes that contract, and finally how Orval can generate TypeScript clients and types from it. Once I saw the whole flow, it became much easier to understand how it keeps the frontend and backend aligned.
As for how much code I actually wrote, I would say it was a combination of AI-generated code, my own code, and a lot of reviewing, debugging, modifying, and connecting the pieces together. Replit Agent helped me move much faster, but I still had to understand the architecture, make decisions, test things, and fix problems when the generated code was not quite right.
I completely agree with your point about wanting to learn how websites are actually made rather than just asking AI to generate everything. I think AI works best as a learning accelerator. Ask it to explain the code it generated, change one part yourself, break something intentionally, and then figure out why it broke. That process teaches you much more than simply copying the output.
If I were starting from a basic todo app, I would roughly go:
For resources, I would prioritize official documentation and small projects over trying to consume hundreds of tutorials. Build something, get stuck, research that specific problem, and then continue. That's basically the approach I followed with GiveTrack.
And honestly, you don't need to understand everything before starting a project like this. You can learn a lot of the architecture while building it, as long as you take the time to understand the code instead of blindly accepting what the AI generates.
Thanks again for reading the article and for asking such thoughtful questions!
This is a really thoughtful project idea. I like how it turns something as personal as generosity into something trackable and reflective. Often, small acts of kindness happen quietly and we don’t take time to understand the impact they create.
Building a tool that helps people visualize and appreciate their contributions is a great example of using technology beyond productivity and efficiency. It shows how software can also support positive habits and human connection.
Great work on combining a meaningful concept with practical development. Looking forward to seeing how GiveTrack evolves!
Thank you so much for this thoughtful comment, it really means a lot! You put into words exactly what I was hoping to capture with GiveTrack. You're right that small acts of generosity often just pass by, without us ever pausing to see the pattern or the impact behind them. I wanted to build something that gave that quiet habit a bit of visibility.
I also love how you framed it: tech in service of human connection rather than just productivity. That's honestly the direction I want to keep pushing this project in.
Really appreciate you taking the time to read through it and share such kind feedback. More updates on GiveTrack coming soon! 🙌
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.
Really solid weekend build. I like that GiveTrack treats giving as something to reflect on over time instead of just a one-off transaction, the Generosity Chain is a smart way to make that visible. Keeping it local-first with demo data was the right call too, since it let you spend the limited time on the actual UX instead of payment infrastructure and compliance work.
The monorepo setup with Zod validation and Orval-generated hooks from an OpenAPI spec is impressive for something built in a weekend, that's the kind of foundation that usually gets skipped under time pressure. Nice touch adding a deterministic fallback for the AI assistant too, so a flaky Gemini call never breaks the demo.
Curious whether you'll eventually connect the kindness prompts to the causes people have already searched for, seems like an easy way to make the suggestions feel more personal. Great execution overall.
Thank you so much! 🙌 Really appreciate you noticing the product and engineering decisions behind the build. Connecting kindness prompts with searched causes is definitely something I’d love to explore next, it could make the experience much more personal. ❤️
GiveTrack is a great concept, most tracking apps focus on money in vs money out, but framing giving as a habit worth reflecting on is a much more human angle. The Generosity Chain is a nice touch, since it borrows the streak mechanic without making it feel gamified in a shallow way. Keeping things local-first for the weekend was smart too, it let you spend the time on the experience instead of payment infrastructure and compliance. Really like that the AI assistant has a deterministic fallback, that's the kind of detail that shows real product thinking, not just a demo hack. Would love to see this evolve into something with real giving flows down the line. Solid build for a weekend timeline.
Thank you! 🙌 That was exactly the idea behind GiveTrack, to make giving feel like an ongoing habit rather than just a transaction. Really glad the Generosity Chain and AI fallback stood out to you. Excited to see where this can go beyond the weekend build! ❤️
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.
Really solid execution for a weekend build. I like that the "Generosity Chain" reframes giving as something ongoing rather than a one time transaction, that's a smart way to lean into the theme instead of just building a donation form. Keeping it local first was the right call too, it let you spend the time on the actual UX instead of fighting payment compliance.
The tech stack is impressive for a 48 hour timeline, a full pnpm monorepo with Drizzle, Zod, and OpenAPI/Orval keeping frontend and backend in sync isn't trivial to set up from scratch, let alone ship. And having a deterministic fallback for the AI assistant is a detail a lot of people skip until it bites them during a live demo.
Curious whether you'd consider letting the "AI Giving Assistant" pull in causes from your searchable list rather than general suggestions, since that seems like the natural next step once you move past local storage. Nice work, this feels like a real product, not just a challenge submission.
Thank you so much! 🙌 I’m glad the product and technical foundation came through despite the 48-hour timeline. Connecting the AI Giving Assistant directly with searchable causes is definitely a great next step. Appreciate the thoughtful feedback! 🚀
Some comments may only be visible to logged-in visitors. Sign in to view all comments.