Context
As part of Commit the Change, I’ve been actively contributing to the community by developing software that supports local non-profits. One of our major initiatives this year was a project I led as the technical director. Like any large-scale effort, it felt just like a professional endeavor - an ongoing, evolving process that saw the project take on many fundamental changes, from the initial design all the way through to deployment.
Summary
Feeding Pets of the Homeless (FPH) connects volunteer donation centers that collect pet food. These centers send the donations to food banks, where homeless individuals can access food for both themselves and their pets when they visit.
The Nonprofit
"Feeding Pets of the Homeless believes in the healing power of companion pets and of the human/animal bond, which is very important in the lives of people experiencing homelessness. They find solace, protection, and companionship through their pets. They care for their pets with limited resources so they themselves have less. Our task, nationwide, is to feed and provide basic emergency veterinary care to their pets and thus relieve the anguish and anxiety of homeless guardians who cannot provide for them."
The
Problem
As a large-scale organization with entirely manual processes, FPH faced several significant challenges:
​
-
Lack of communication between donation sites and FPH
-
A complicated onboarding process
-
Manual data entry for all records
-
Donation sites wanted better visualization tools to track their progress
These were the main issues we aimed to address in the project.
Requirements
Feeding Pets of the Homeless
Donation Sites / Businesses
They can view all the information of all the donation sites and send reminders to them.
They can view the information of their own site as well as submit donation sheets.
Tech Stack
Design Stack:
​
Figma, Figjam, Chakra UI, KitTech Stack
Frontend:
React, JavaScript, HTML, CSS
​
Backend:
​
NodeExpress, JS, AWS, Firebase (authentication)
Database:
​
PostgreSQL, PG Admin
Needs
Audience
Requirements
UI/UX
Database
Information
Before any code gets written, it's crucial to spend time on design. There are a few key areas to focus on, which I’ve highlighted here. Of course, this isn't everything - things like User Flows, Architecture Designs, and more are equally important but left out for now. These designs form the backbone of the implementation and serve as a guide through every stage. And if we hit any major roadblocks, we always revisit these foundational stages (which happened many times, especially with the database design - what you see here is actually the fourth version!).
Implementation
Implementation
To bring our project to life, we worked as a team using sprint-tasks (which probably sounds familiar!). We carefully considered the scope of each task, broke down the entire project into steps that could be tackled incrementally, set up a GitHub repository, and started dividing tasks. We based this on factors like task difficulty, importance, the developer or designer's skill level, and how independently the task could be completed. Each week, we held code reviews to evaluate pull requests from teams of two or three, provided feedback, and followed up on any fixes or minor tweaks. This cycle of assigning, completing, reviewing, and refining tasks was repeated until the project was finished.
Our Project lifespan...
Onboarding Page
FPH Dashboard
Notification Center
Donation Items
Gallery
Get a feel for the project through these wireframes
GitHub
Problems
A project always comes with a few mistakes, and I'd like to highlight some of ours. The first major one was with our Git setup - we initially decided not to restrict access to the main branch. This turned out to be a big mistake because we ended up accidentally pushing to main far too many times. We definitely underestimated the issues this could cause, and I learned that prevention is always better!
We also ran into problems with the database architecture. We realized we needed certain interactions and relationships between databases that hadn’t been accounted for in the original design. This forced us to redesign the schema from scratch, even though we were already deep into the process. While it seemed daunting at first, it turned out to be manageable thanks to the organized structure we had in place.
During the final stretch of the project, our sprint tasks shifted entirely to bug identification and resolution. Yes, we actually had tasks specifically for finding bugs, and we even rewarded those who managed to uncover them! We organized and documented each bug with the following details:
-
Identifier
-
Affected page
-
Bug description
-
Steps to reproduce it
Debugging
With regard to the NPO, we were in constant communication with them throughout the project. We regularly updated them on our progress, asked additional questions when new challenges arose, and received ongoing advice and guidance. To streamline this process, we even set up a dedicated Slack server just for emails to ensure that communication and feedback were prioritized.
In conclusion, this project was a collaborative effort that saw our team navigate through every phase of development, from initial design to the final deployment. By breaking down tasks incrementally and organizing our workflow with sprint tasks, we were able to complete a complex, large-scale project while addressing challenges along the way, such as database redesigns and bug fixes. Our structured approach to task assignment, code reviews, and documentation helped keep us on track throughout the process.
Conclusion
Reflection
Reflecting on the experience, it was clear that flexibility and attention to detail were key to our success. We learned valuable lessons about the importance of proper setup (especially with Git), the need for ongoing design adjustments, and the power of team collaboration. This project not only improved my technical skills but also reinforced the value of planning, communication, and continuous improvement in software development.