This is a submission for Weekend Challenge: Generosity Edition
What I Built
I built a gamified donation platform where every donation helps you build and grow your own virtual city. Donations to different causes unlock or upgrade buildings, giving donors a visual sense of their impact.
The platform also includes leaderboards and challenges, turning donations into a fun, social experience. You can even donate on behalf of someone else, helping build their city and encouraging them to join and donate themselves.
The goal is simple: make giving more engaging, visible, and motivating, while encouraging people to donate more.
Demo
Code
https://github.com/hussainshaikh12/donate-city
How I Built It
How the Idea Evolved
I actually started this project with a much simpler idea. I wanted to build something similar to outgive.lol — a donation leaderboard where people could compete to become the biggest donor. I thought it was a simple but really engaging concept.
But when I started looking into it, I realized that several people had already built similar projects around the same idea. So instead of building another version of the same thing, I started thinking about what else could make donating feel more engaging.
That is where the idea of building a city through your donations came from.
The concept became: what if every donation actually built something? Instead of your donations just being numbers on a dashboard, each donation would have a visual representation in your own city. Different causes could become different buildings, and donating more could upgrade those buildings.
The leaderboard idea didn't disappear — it became a secondary feature. I kept the Outgive-style leaderboard, where you can see the top donors and how much you need to donate to overtake them. But instead of the leaderboard being the entire product, it became one of several game mechanics around the main idea of building your city.
I also didn't initially plan to make AI a major part of the project. My original plan was to manually create the game assets and build the city using those assets. As I started building, however, I realized how much time was going into creating, fixing, and iterating on assets.
That led me to use Nano Banana for dynamic building asset generation and Gemini for campaign discovery and trending humanitarian events.
What started as a simple donation leaderboard gradually turned into a small donation game with a dynamic city, social features, competition, and AI-powered functionality.
Core Platform
I built the application using Next.js (App Router) and Supabase (PostgreSQL + Auth).
I started with the basics — authentication, user profiles, and the donation flow — before building the game layer around them.
For donations, I chose Every.org primarily because it had a straightforward API and was relatively easy to integrate. Since this was a hackathon project, I wanted to spend my time building the actual product experience rather than building an entire donation and nonprofit infrastructure from scratch.
The intended donation flow is:
User → Every.org → Donation confirmation → Update donation data → Update city
I have built the application around this flow, but since I have not deployed the project, I have not yet completed the production webhook configuration. The next step would be to deploy the application, expose the server-side webhook endpoint, and configure that endpoint with Every.org so confirmed donations can automatically update the user's city.
Isometric City
The main idea was to make donations visual, so I integrated Phaser 3 into the Next.js application and built a simple isometric city.
The game itself is intentionally simple. It has a green grass-based environment, roads, and buildings. There are no complex animations, combat systems, characters, or elaborate game mechanics.
The core loop is:
Donate → Build → Upgrade → Explore
When you donate to a cause, a building is created. Additional donations to that cause increase its progress and eventually upgrade the building.
I originally wanted to spend much more time making the game itself visually complex, but I quickly realized that asset creation, alignment, animations, and small visual fixes were taking more time than building the actual product features.
So I decided to keep the game layer simple for now and focus on getting the core experience working.
The important part is that the foundation is there. More animations, richer environments, interactions, and traditional game mechanics can be added later without having to rebuild the underlying donation system.
Building Levels & AI-Generated Assets
Buildings have multiple levels and visually change as the associated cause receives more donations.
One of the more interesting parts of the project is that I didn't want every building asset to have to be manually designed.
I integrated Nano Banana to generate building artwork based on the cause and building level. This means the system can generate assets for different causes instead of relying entirely on a fixed collection of manually created images.
For the current version, these generated assets are stored locally inside the project's public/assets/buildings/ folder. This works well for the hackathon prototype because the assets I have already generated can simply be used by the game.
The dynamic generation itself currently writes the generated images to the local filesystem. Since I am not deploying this version, that is fine for the current prototype.
If I were to take this into production, I would move dynamically generated assets to persistent storage such as Supabase Storage instead of writing them to the application filesystem.
Donation & Campaign Discovery
Users can explore the campaigns behind their buildings. Clicking a building shows information about the cause and the donations associated with it.
There is also a campaign discovery section where users can search for something specific they want to support rather than being limited to a fixed list of campaigns.
This makes the city more than just a visualization of donations — each building represents a real cause that the user can explore and support.
Trending Causes
I wanted the platform to surface causes that people might not otherwise discover.
A daily background job looks at current humanitarian events, identifies emerging issues, and finds relevant campaigns on Every.org.
These campaigns are then surfaced in the trending section so the donation experience can react to what is happening in the real world.
This is where Gemini becomes useful. Instead of maintaining a manually curated list of trending causes, the system can use current events as an input for discovering issues and relevant campaigns.
Donate on Behalf of Someone
Another feature I wanted was the ability to donate on behalf of someone else.
You can make a donation for another person and attach a message.
If they don't have an account, the donation is staged until they sign up. Once they join, the donation becomes part of their city and the corresponding building is created.
If they already have an account and already support that cause, the donation contributes toward their existing building and can help upgrade it.
The idea is to create a natural invitation into the platform: someone receives a notification that another person built something in their city, comes to see what happened, and potentially starts donating themselves.
Visiting Other Cities
Users can visit other people's cities and see how they have built them.
This was inspired by games I played growing up, such as Clash of Clans and Dragon City, where visiting another player's world makes the experience feel much more social than simply looking at a leaderboard.
Instead of only seeing that someone donated a certain amount, you can actually see the result of those donations inside their city.
Leaderboards & Outgive
The original inspiration for the project is still present here.
There are daily and all-time leaderboards, and users can see who is currently at the top and how much they would need to donate to overtake them.
This turned the original Outgive-style concept into a smaller mechanic inside the larger game.
It adds a competitive element without making competition the entire reason to use the platform.
Profiles & Privacy
Users have profiles where they can add a bio and control how they appear to other users.
There is also an anonymous mode and an option to prevent other people from visiting their city.
This gives users control over how much of their donation activity they want to share publicly.
Gemini API
I initially wasn't planning to use Gemini at all. Once the core platform was working, though, I realized there were places where AI could make the product itself more useful.
I ended up using Gemini in two main areas.
Trending causes: I created a daily cron job that looks at current news and humanitarian events. Gemini helps identify and categorize emerging issues, and I then use that information to find relevant campaigns from Every.org and surface them in the trending section.
Campaign search: Gemini is also used when users search for campaigns. Instead of requiring users to know the exact category of a campaign, Gemini interprets their search and helps determine the relevant cause and category.
So Gemini wasn't just used during development — it became part of the actual product experience.
Nano Banana — Dynamic Building Generation
Nano Banana came from a problem I encountered while building the game.
I initially planned to generate a fixed collection of building assets and use them throughout the game. But I quickly realized that if I had many causes and multiple upgrade levels, I would need to manually create a huge number of assets.
So I changed the approach and made the asset generation dynamic.
When a new cause needs a building, or a building reaches a new level, the system can send a structured prompt to Nano Banana and generate the corresponding isometric building.
This means I don't need to maintain a massive library of manually created assets, and the number of possible building levels can continue to grow.
Learning to Prompt Efficiently
The first version of my Nano Banana prompts was also much more complicated than it needed to be. I was giving the model very long prompts with lots of instructions, which resulted in unnecessary token usage.
I had to experiment and gradually reduce the prompts to the essential information needed to maintain the visual style and generate the correct building. That made the generation process significantly more efficient.
Solving the Transparent Background Problem
Another unexpected problem was that the AI-generated buildings were returning with solid backgrounds instead of transparent ones.
I solved this by asking Nano Banana to generate the building on a predictable magenta (#FF00FF) background.
On the server, I then process the generated image using Jimp. A small flood-fill/BFS algorithm starts from the corners of the image, identifies the connected magenta background, accounts for slight color variations using a tolerance, and converts those pixels to transparent.
I then resize the processed image to the standard dimensions used by Phaser before using it as the building sprite.
What I Would Build Next
The current version focuses on proving the core concept: turning charitable donations into something visual, social, and game-like.
If I continued developing it, the next steps would include moving dynamically generated assets to persistent storage, completing the production Every.org webhook integration, adding more sophisticated game mechanics and animations, expanding the range of causes and building types, and making the city itself more interactive.
The underlying idea would remain the same:
Your donations don't just become a number — they become a city.
AI & Vibe Coding
This was my first time building a game, so I heavily vibe-coded the project. I would have an idea for a feature, try to implement it, run into something I didn't understand, and use AI to help me work through the problem and keep moving.
The important part was that I was still steering the product — deciding what I wanted to build, changing the approach when something wasn't working, and iterating on the result.
What Vibe Coding Changed for Me
The biggest advantage of AI during this project wasn't simply generating code. It was helping me get past things I didn't know how to solve.
Since I had never built a game before, I had to learn about Phaser, image processing, database triggers, webhooks, asset pipelines, and a lot of small game-development problems while actually building the product.
I also learned that the seemingly insignificant things can consume the most time. Fixing one UI alignment, adjusting an asset, getting two images to match, or fixing a small styling issue can take hours. At times, I realized I was spending more time fixing those things than building the features that actually mattered.
AI helped me move through those problems much faster. That meant I could keep building features and still spend meaningful time refining the UI.
The game is simple right now, but it works. And because I focused on getting the core systems right first, I now have a foundation that I can continue expanding with better graphics, animations, richer environments, and more game mechanics later.
Prize Categories
Best Use of Google AI: I integrated Google AI in two powerful ways. First, I used Google Gemini to power the core discovery mechanic, parsing live unstructured global news feeds into actionable charity categories to surface real-world crises. Second, I used the Nano Banana API to dynamically generate custom isometric 2D assets on the fly whenever a user unlocks a new cause or building level, allowing the visual city to scale infinitely without manual asset creation.
Top comments (0)