This project started as a CS 137 Software Engineering 1 requirement, where we were asked to design a system that could genuinely help our local community. We focused on correctional facility visit operations because many processes were still manual and difficult to audit in real time.
The core problem we targeted was friction and uncertainty in visitor flow: identity checks, time tracking, and record retrieval often depended on manual logs. Our solution was a QR-based Visitor Management System where each approved visitor receives a unique QR code that can be scanned for controlled check-in and check-out.
We used Laravel 11 with PHP 8.2 and MySQL because the stack gave us fast development for a structured CRUD-heavy system while keeping authentication, routing, validation, and database workflows maintainable. On the UI side, we used Blade templates with Bootstrap and JavaScript for practical and accessible admin/visitor screens.
QR generation was implemented through the simple-qrcode package, and visitor QR files are served from protected storage paths. This allowed us to avoid exposing raw assets publicly while still letting authenticated users retrieve their own generated QR code safely.
The system flow is role-aware. Visitors register and verify email before fully accessing account features, while admin/moderator workflows handle inmate management, pending approvals, blacklisting, and visit status updates. This separation keeps responsibilities clear and reduces misuse risk.
Scanner operations are guarded by validation checks in the check-in/check-out process: invalid QR rejection, blacklist blocking, prevention of duplicate active check-ins, inmate validation, and state-based constraints for visit completion. These controls were important because a small logic gap could produce inconsistent visit records.
Visit records are tracked through explicit states (pending, ongoing, completed, rejected, force-ended), with duration computed from check-in/check-out times. We also integrated audit logging so key actions are traceable, supporting both operational monitoring and post-incident review.
For administrators, we added search, filtering, sorting, and pagination on logs to keep the system usable as records scale. Analytics views (daily/weekly/monthly) were added to support reporting and identify patterns in visitation activity.
Beyond features, this project taught us practical software engineering tradeoffs: balancing delivery speed with security controls, designing for real users under operational pressure, and translating academic requirements into a system that can create measurable local impact.
Project context: CS 137 Software Engineering 1 community-focused solution
