Building Loyola Alumni Platform
Visit →Background
Loyola's alumni network is one of the school's strongest assets. From the student side, however, much of it is invisible. You can know the network exists without knowing who is in it, what they do, or how to ask for help responsibly.
I built Loyola Alumni Platform out of that gap. The first version is a public capstone site with documentation and a searchable sample directory. The longer-term version is a school-owned system for student-alumni introductions.
Product
The product has two surfaces. The first explains the capstone: problem, research, design decisions, implementation, and next steps. The second is a directory experience that lets students search by industry, role, company, class year, and willingness to help.
The deployed version uses anonymized sample data. That constraint is intentional. The platform is meant to prove the workflow before any real alumni records are handled.
Architecture
The app is built with Next.js, TypeScript, Tailwind, MDX, and Fuse.js. The writing lives as route-level documentation. The directory is a focused search surface over structured alumni records.
The data layer is deliberately conservative. A zod schema defines the record contract, sample JSON is validated at read time, and a local CSV importer validates real exports before writing to gitignored files. Real data is excluded from the repository by default.
Institutionalization
The hard part is not another interface pass. The hard part is trust. A directory of people requires consent, access control, revocation, and a clear owner inside the school.
The next version should be narrow: a password-gated directory, consent-aware records, student request-introduction flow, admin review path, audit trail, and a handoff playbook that lets the system survive after I graduate.
What I learned
A network becomes more valuable when people can navigate it. It also becomes more sensitive. Privacy and maintenance are not side concerns here; they are the product boundary.
The project clarified the difference between a demo and a platform. A demo proves the idea. A platform needs ownership, policy, trust, and a workflow simple enough for a school office to keep running.