Impact Desk
ImpactDesk is a fundraising activity planner for nonprofit fundraising managers and development staff who need to organize donor meetings, visits, and events more efficiently. Users schedule relationship-building activities, filter them by day, and view addresses on an interactive map to plan routes.
Individual project for the Code Platoon capstone. React frontend with Material UI and React Leaflet, Django REST Framework backend, PostgreSQL, deployed on AWS EC2 with Docker.
GitHub Live DemoPurpose and Goal
I've done nonprofit fundraising work, and tracking relationships, schedules, and events across spreadsheets and calendars gets messy fast — especially the visual piece of seeing where everyone is and planning a route between them. Working with nonprofits and churches over the years gave me a clearer picture of what fundraising and development staff actually need day-to-day.
I researched the role specifically before scoping the build — including how outreach actually breaks down day-to-day, which is why scheduling and routing are the app's center of gravity rather than data.
I started with a planning document, a defined Minimal Viable Product (MVP), and rough page sketches before writing code.
Spotlight
The hardest part of building the development scheduling page wasn't the core functionality — it was the form. I designed it to handle scheduling, location lookup, contact linking, and validation in one form. It has twelve inputs total. The scope created cascading bugs, but the bigger problem was one I only saw after completing.
Scheduling doesn't happen all at once in real life. A person knows a contact's name today, sets a meeting time tomorrow, and confirms the address. One data model and one form is a good beginning, but it forces a person to know everything upfront. I'd redesign it now to match better user workflow. Having partial records that fill in over time, nullable fields and plan for "in-progress" states. The database and frontend can be done very differently with this in mind.
Lessons Learned
One thing I'd take from this build: features are bigger than they look, and choices for the visual and user experience are often choices about the code not seen.
Getting a map onto the screen is its own engineering problem. So is putting markers on the map, an address search, geocoding, gps location, and drawing routes. The apps we use every day are built from thousands of small steps, each one solved separately. That will change how I plan: breakdown first, estimate the parts, and finish one piece at a time.
