AlumniPortal
A living network for a graduating institution
- Role
- Full-stack developer: schema, backend, interface
- Year
- 2023
- Discipline
- Full Stack · Databases · Product
- Context
- A multi-role web platform for alumni engagement, built with PHP and MySQL on a normalised schema.
Institutions lose contact with their graduates almost immediately. The knowledge, the job referrals and the mentoring capacity all leave with them, and what remains is usually a spreadsheet nobody maintains.
This portal replaces that spreadsheet with a system three distinct groups actually have reason to open: alumni who want to stay reachable on their own terms, students looking for people who have already walked the path, and administrators who need the whole thing to stay accurate without manual policing.
What madethis hard.
- 01
Three audiences, one database
Alumni, students and administrators need different views, different write permissions and different privacy defaults. Modelling that as one flat user table produces authorisation logic scattered across every page.
- 02
User-supplied input reaching SQL
Directory search, profile editing and the job board all take free text and put it near a query. String concatenation here is how portals get emptied.
- 03
Search that stays fast as the directory grows
Filtering by graduation year, degree, industry and location simultaneously is a query that degrades quickly if the schema and indexes aren't designed for it.
- 04
Privacy is not optional in an alumni context
Contact details belong to the graduate, not the institution. Visibility has to be per-field and controlled by the person the data describes.
How Isolved it.
- 01
Normalise first
A third-normal-form schema with explicit foreign keys and join tables for the many-to-many relationships (alumni to employment history, alumni to mentorship interests) so integrity is enforced by the database rather than by hopeful application code.
- 02
Role-based access at the boundary
Permissions resolve on every protected request, not just at login. Session identifiers regenerate on privilege change, and access checks live in one shared guard rather than being re-implemented per page.
- 03
Prepared statements everywhere
Every query is parameterised, with output escaping applied at render time. Input validation is server-side authoritative, and client-side checks improve the experience without ever being trusted.
- 04
Indexed, composable search
Composite indexes on the fields that are filtered together, with pagination pushed into the query rather than applied after the fact.
- 05
Per-field visibility controls
Each profile field carries its own visibility setting, resolved server-side before serialisation so a hidden field never reaches the client to be hidden with CSS.
What itdoes now.
A single schema serving three permission tiers without duplicated authorisation logic.
A searchable directory with multi-criteria filtering and server-side pagination.
Events, an opportunities board and mentorship matching sharing one identity and notification layer.
Parameterised queries and server-authoritative validation across every input surface.
Backend
- PHP
- Session Auth
- REST
Frontend
- HTML
- CSS
- JavaScript
Data
- MySQL
- Normalised Schema
- Composite Indexes
Security
- Prepared Statements
- RBAC
- Output Escaping
HospitalManagement
A clinical operations system covering patient records, appointment scheduling, staff rostering and billing, designed around a domain model where the hard constraints are enforced in one place.
Read case study