Option A — What was built

Present is a complete Laravel 11 application. Authentication piggybacks on Pharos360's PHPSESSID cookie — if a user is logged into Pharos360, Present reads their session and logs them in automatically. Courses, students, and photos come from the shared PostgreSQL database. Attendance data is stored in the roster_* tables.

The Laravel app has controllers, Blade views, Eloquent models, and middleware — standard Laravel MVC. It is clean, readable, and well-structured. The cost is that the team would need to learn and maintain Laravel, and every client deployment requires a second server running PHP-FPM.

Option B — What was built

The integrated module adds seven new PHP pages to Pharos360's site/ directory, five helper functions to classes/queries.php, and small edits to three existing files (partials/userland.php, settings.php, login.php). No new tables — it uses the same roster_* tables Present uses. No new server, no new framework, no new deployment process.

What Option B does not yet have

• Email: Notify Absent Students — the button exists on the Take Attendance page but the handler (attendance_email_notify.php) was not built
• Email: Summary to Me — same situation (attendance_email_summary.php)
• Test coverage — no automated tests; the same gap that exists across Pharos360 generally
• Full developer review — the code was written in a single AI-assisted session and needs a developer to read it before production

Auth and session — both options

Faculty access attendance the same way in both options: they log into Pharos360 and click Attendance in the top navigation. Option A takes them to the standalone Present app (via roster.php redirect). Option B takes them to attendance_courses.php inside Pharos360. The nav entry point is identical; the destination differs.

In a client deployment, only one option would be active at a time: roster_url set → Option A; has_attendance enabled → Option B.

Database

Both options use the same roster_* tables in the shared PostgreSQL database. If a client were to switch from Option A to Option B (or vice versa), no data migration would be needed.

Both approaches were built against fake data in a local Docker environment. Neither is production-ready without:

• A test suite — every save, every status cycle, every export path needs automated coverage before real student data is in play
• Security review — auth gates, input validation, and SQL parameter handling need a developer read-through; this applies especially to Option B's new pages which modify a live codebase
• A staging environment — no CI/CD pipeline exists for either app; changes go directly from development to production
• Load testing — neither has been run against a class roster larger than the local fake data set

If the decision is purely operational

Option B wins on every operational dimension — no new infrastructure, one deployment to maintain, per-client toggle, same team skills. The missing email notifications are a few hours of work. The developer review is the same work that would be required for any new Pharos360 feature.

If the decision is about code quality and architecture

Option A is cleaner. Laravel enforces separation of concerns, the codebase is testable by design, and bugs stay isolated from Pharos360. For a team willing to invest in learning Laravel and provisioning per-client infrastructure, it is the more defensible long-term choice.

What AI-assisted development revealed

Option B was built — seven pages, five helper functions, the feature flag, the nav wiring, and the database write — in a single afternoon session. The Pharos360 PHP patterns are simple enough that an AI can produce working code quickly. Option A took longer to rewrite (it replaced a full Java application) but ended up more structured.

The comparison is not "which one is better code" but "what trade-off fits the team and the clients." Both are real, running, and usable today.

Both options are running in Docker on this machine. Use the flows below to see each one.