Building a Secure Nonprofit Decision-Support Platform in Five Days

Project Beacon was a simulated client engagement based on the work of Lighthouse Sanctuary, a nonprofit that supports safe homes and rehabilitation services for girls who have survived abuse or trafficking in the Philippines. We were not building for Lighthouse Sanctuary itself. We used anonymized operational material to design a platform for a hypothetical new organization with similar needs.

The organization needed one system to manage donors, resident care, safehouse operations, outreach, and public impact. It also needed to protect highly sensitive information about minors while helping a small staff make better decisions.

The central problems were broad:

• Which donors may stop giving, and who may be ready to give more?
• Which residents need attention, and who may be ready for reintegration planning?
• Which social posts lead to donations instead of only likes and views?
• Which safehouses may face capacity or resource pressure?
• How can the organization show impact without exposing private resident data?

The project combined requirements from project management, application development, cybersecurity, and machine learning. We completed four one-day sprints from Monday through Thursday and presented the final product on Friday.

I served as the Scrum Master, a developer, and the machine-learning lead. My role crossed project coordination and hands-on technical delivery.

• Helped turn the project brief into a product plan and backlog.
• Organized work in Trello and supported daily sprint planning.
• Kept project documentation current.
• Researched the dataset and identified the most useful business questions.
• Designed and built the machine-learning workspace and pipelines.
• Helped package model outputs for backend and frontend use.
• Supported integration and problem solving across the application.
• Mentored a teammate who had less development experience.

The four-person team included:

• Nathan Trotter
• Jake Gunnell
• Jazzive Vizcarra
• George Ramsay

All four of us contributed as developers. We worked together in person for much of the week, often spending the full day in the same apartment so decisions and integration could happen quickly.

One teammate took a strong role in frontend direction and product vision. I focused on Scrum facilitation, machine learning, documentation, and helping the different pieces reach a working final product.

A basic solution could have been a set of forms and dashboards. We wanted the product to do more than display records. It needed to help staff understand what mattered and decide what to do next.

We framed the product as:

A secure decision-support platform that connects donor activity, resident progress, outreach performance, and public impact into one operational system.

That framing led us to ask four questions on each important page:

• What changed?
• What needs attention?
• What action should the user consider?
• Why is the system surfacing this information?

The provided dataset contained 17 related tables across three main areas. The challenge was not simply loading those tables. We needed to turn them into connected workflows.

We used these relationships to connect donations to allocations and impact, social posts to donation referrals, and resident activity to risk, progress, and safehouse performance.

I owned the machine-learning portion of the project. I began with the decisions the nonprofit needed to make, not with a preferred algorithm. After reviewing the data, I defined 13 predictive questions.

Each pipeline included a business question, prepared data, engineered features, model training, evaluation, saved outputs, and a recommended place in the application.

A machine-learning notebook is not useful by itself. The result needs to change what a user sees, prioritizes, or does.

I organized the ML work into reusable Python modules, notebooks, model artifacts, evaluation reports, tests, API payloads, and application-integration examples. Model outputs were designed for product surfaces such as:

• Ranked donor and resident lists
• Risk and readiness indicators
• Recommendation panels
• Explanation summaries
• Safehouse forecasts
• Dashboard insights

We also created a scheduled refresh process so models could retrain and publish new predictions as the underlying data changed. The frontend received those results through backend endpoints instead of connecting directly to the database.

The simulated data represented vulnerable minors, donors, staff, and partner organizations. Privacy could not be treated as an item to add at the end.

The product included or planned for:

• HTTPS and secure credential handling
• Username and password authentication
• Role-based access for public, donor, and administrative users
• Protected application endpoints
• Confirmation before deleting data
• Privacy documentation and cookie consent
• Content Security Policy protections
• Anonymized public impact reporting
• Restricted access to sensitive resident information

We also intentionally excluded real-time resident surveillance and other monitoring that could create unnecessary risk or violate the privacy of minors.

By Friday, the team had a deployed product that connected public communication, authentication, donor workflows, resident case management, dashboards, reports, security, and machine learning.

• Delivered the required public and authenticated application experiences.
• Connected a relational database across 17 operational tables.
• Supported donor, donation, resident, counseling, visitation, and reporting workflows.
• Implemented role-based access and protected functionality.
• Built 13 predictive pipelines around specific organizational decisions.
• Packaged machine-learning outputs for backend and frontend use.
• Demonstrated the product and end-to-end workflows to a client-style panel.

This was an academic, simulated-client project, so the result should not be presented as live nonprofit adoption. Its value is the breadth and completeness of the working delivery under a severe time limit.

View the Project Beacon repository

Competing directions created rework

Early in the sprint, most of the team continued building the first application while a competing frontend direction was developed separately. The alternative looked stronger in several ways, but adopting it required us to move and rebuild work during a five-day project.

Experimentation was not the problem. The team lacked a shared process for time-boxing the experiment, comparing the options, and making a final decision before parallel work became expensive.

We prepared the presentation too late

I raised concerns about presentation readiness several days before the final demo, but we kept prioritizing the application. Serious rehearsal began only shortly before presenting. Transitions and speaking roles were less clear than they should have been, so the presentation did not communicate the product as well as the product deserved.

The value was not immediately visible

We prioritized architecture, security, useful workflows, and operational machine learning. The panel also responded strongly to small, memorable features that were easy to see during a short demo. We learned that a strong foundation still needs one or two clear moments that make its value obvious.

Product ownership only works when the whole team understands who owns direction, how alternatives are evaluated, and when a decision becomes final. A strong personal vision is not enough if it does not create shared movement.

I also learned that Scrum Master work is more than tracking tickets. It includes protecting alignment, surfacing competing directions, and making sure important discussions happen before they become rework.

Finally, I learned that the presentation is part of the product. Good architecture and thoughtful features do not speak for themselves. The team needs to make the business value easy to understand, remember, and trust.

Project Beacon showed me that I enjoy working where product planning, team coordination, software, data, and machine learning meet. I can build technical systems, but I am most interested in making sure those systems help people make better decisions.