Five Days to Turn 17 Tables into a Working Product

On Monday, our team received a 17-table nonprofit dataset. By Friday, we had to demonstrate a secure application connecting donor management, resident care, outreach, reporting, and predictive models. The scope was broad. The harder challenge was deciding what mattered enough to finish.

Project Beacon was a simulated client engagement based on anonymized operational material from Lighthouse Sanctuary, which supports safe homes and rehabilitation services for girls who have survived abuse or trafficking in the Philippines. We designed for a hypothetical new organization with similar needs, not for Lighthouse Sanctuary itself.

The data represented vulnerable minors, donors, staff, and partner organizations. The system needed to help a small staff act on complex information without exposing sensitive resident details or turning surveillance into a product feature.

The team was Nathan Trotter, Jake Gunnell, Jazzive Vizcarra, and me. We spent much of the week working together in the same apartment so decisions and integration could happen quickly. I served as Scrum Master, developer, and machine-learning lead, moving between backlog planning, technical delivery, documentation, integration, and teammate support.

A basic solution could have been a collection of forms and charts. We wanted each important page to help a user answer four questions: What changed? What needs attention? What action should I consider? Why is the system surfacing this information?

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

The 17 tables fell into three connected domains. The value came from relationships across them, such as linking donations to allocations and impact, social posts to donation referrals, and resident activity to risk, progress, and safehouse capacity.

I personally built all 13 predictive pipelines. Rather than beginning with an algorithm, I reviewed the data and started with decisions the organization might need to make. That led to 13 predictive questions across fundraising, outreach, resident care, and safehouse operations.

Each pipeline included a business question, prepared data, engineered features, training, evaluation, saved outputs, and a defined place in the application. I organized the work into reusable Python modules, notebooks, artifacts, reports, tests, API payloads, and integration examples so the models would not end as isolated experiments.

The product consumed model results through backend endpoints and translated them into ranked lists, risk indicators, recommendation panels, explanation summaries, and forecasts. We also designed a scheduled refresh process so predictions could be republished when the underlying data changed.

Privacy shaped the implementation from the beginning. We used role-based access, protected endpoints, secure credential handling, confirmation for destructive actions, anonymized public reporting, and restricted access to resident data. We deliberately excluded real-time resident surveillance and similar monitoring that would create unnecessary risk.

Early in the week, most of the team continued building the first application while a stronger competing frontend direction developed separately. The experiment itself was useful. The problem was that we never clearly time-boxed it, compared both options, and made the decision final before parallel work became expensive.

When we adopted the alternative direction, parts of the project had to move or be rebuilt during an already compressed delivery window. The team still reached a working product, but integration consumed time that could have gone toward polish, rehearsal, and making the value easier to see.

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

The panel also responded strongly to small, memorable features that were immediately visible. We had prioritized architecture, security, connected workflows, and operational machine learning. Those were meaningful choices, but a strong foundation still needed one or two clear moments that made its value obvious within a short demonstration.

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

• Connected a relational database across 17 operational tables.
• Delivered public and authenticated workflows for donors, residents, and staff.
• Implemented role-based access and protected functionality.
• Packaged 13 predictive pipelines for backend and frontend use.

Because this was an academic simulated-client project, the result should not be presented as live nonprofit adoption. Its value is the breadth of the working delivery under a severe time limit and the lessons that emerged from building it.

I would now establish clearer ownership of product direction, time-box competing approaches, and treat presentation preparation as part of the sprint rather than something that begins after development. Good architecture does not speak for itself. The team has to make the business value easy to understand, remember, and trust.

Project Beacon reinforced 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.

View the Project Beacon repository