CampusFlow

CampusFlow is an operations platform for student-programming teams. It replaces the tangle of spreadsheets, group chats, and paper forms that most campus offices run on with a single system covering the full lifecycle of an event.

Running 250+ attendee campus events means tracking vendors, budgets, inventory, staffing shifts, attendance, and post-event feedback at the same time. None of that data lived in one place, so reporting was manual and institutional knowledge disappeared every time a student staffer graduated.

One event record that everything hangs off of: budget lines, vendor contacts, inventory reservations, staffing shifts, check-ins, and feedback responses. Role-based views mean a director, a coordinator, and a student worker each see the slice they need.

The planned architecture uses a Next.js front end with a FastAPI service over a typed REST boundary. PostgreSQL will manage relational event data, with object storage for vendor documents and event media. Services are planned to be containerized and deployed through a CI/CD workflow.

Next.js, React, TypeScript, Python, FastAPI, PostgreSQL, Docker, AWS, GitHub Actions.

The current design favors FastAPI for a thin, typed API surface and PostgreSQL because event operations are strongly relational. The frontend architecture is being designed around dashboard-heavy workflows where server-rendered data can reduce unnecessary client-side complexity.

One of the main design challenges is modeling budget approvals and inventory reservations without creating workflows that are too rigid for real event operations. I am exploring explicit state transitions so exceptions can be recorded rather than handled outside the system.

The security design includes least-privilege roles, server-side authorization, protected document access, parameterized database queries, secure secret management, and audit logging for sensitive financial actions.

Currently in the planning and system-design stage. The requirements are based on recurring operational problems observed while managing university programming, including vendor coordination, budgets, inventory, staffing, and event reporting.

Designing for the person doing the work at 7am on event day is a different discipline than designing for a demo. Constraints from real operations produced a much sharper data model than a greenfield spec would have.