Chapter 1. Turning a Service Initiative into a Product
CARA began as a self-initiated volunteer project for a church catechism retreat. The committee needed to coordinate participant data, schedules, activities, and event-day responsibilities without relying on disconnected tools. I framed the solution as an event operations platform, not a conventional information site. I independently handled product framing, architecture, database design, backend, responsive frontend, and deployment preparation. The result combined a simple participant experience with controlled tools for mentors, committee members, game coordinators, and administrators.
Chapter 2. Connecting Identity with Attendance
Registered users accessed a personal ticket through a lightweight phone-number flow. Its unique QR identity connected the participant profile with both main check-in and session-level attendance. Database constraints prevented duplicate records for the same participant and activity. Mentor scanners only accepted QR codes belonging to their assigned mentees. Authenticated committee members could then review the results through a dedicated attendance monitoring workspace.
Chapter 3. Making the Rundown Drive the Experience
The rundown became the central participant hub instead of a static schedule. It combined multi-day agenda information, session attendance, personal notes, and links to devotional material, quizzes, games, and evaluation. Resources opened automatically according to the event schedule, while administrators could manually open or lock them when timing changed. Authorized committee members could request temporary early access through reauthentication. This kept activity access predictable without removing operational flexibility.
Chapter 4. Preserving Quiz Progress and Fair Results
The Bible quiz contained 50 questions, autosaved answers, and a maximum of two attempts per participant. Submission required every active question to have a valid answer, while transactions protected attempt consistency. Automatic scoring removed the need for manual calculation. The monitoring view separated participants who had not started, were still answering, or had submitted. The leaderboard used each participant's best score and submission time as a transparent tie-breaker.
Chapter 5. Translating a Physical Game into Software
Baggage Relay translated a physical team game into a controlled digital workflow. It involved three teams, six sequential stations, assigned PICs and guards, equipment requirements, rank-based scores, and baggage bonuses. Participants could view their team, station instructions, current baggage, and progress from a mobile interface. Every baggage item was tracked independently as active, released, or broken. This made the application both a practical game guide and a live representation of each team's state.
Chapter 6. Keeping Progression and Scoring Consistent
The scoring workflow enforced sequential game progression across all six stations. Pos 1 waited for every team to confirm its baggage, while later stations waited for complete results from the previous stage. Each PIC could score only the station assigned to their account. Final standings combined game points, active baggage bonuses, and recorded penalties in a single database transaction. The resulting live leaderboard remained transparent and protected from partial updates.
Chapter 7. Turning Feedback into Usable Insight
The evaluation flow collected structured ratings and open-ended feedback about both catechism classes and the retreat. Conditional fields and meaningful-text validation improved response quality, while a unique rule limited each participant to one submission. The committee dashboard converted those responses into completion metrics, rating distributions, and written-feedback summaries. Participant and committee responses remained distinguishable for more useful analysis. Administrators could also export the results for post-event follow-up.
Chapter 8. Building for Real Operational Use
CARA was built with PHP, MySQL, and responsive vanilla JavaScript behind a custom front controller. Its data model connected participants, mentors, rundown sessions, attendance, quiz attempts, teams, baggage, scores, penalties, and evaluations. Prepared statements, CSRF protection, database constraints, and transactions protected critical write operations. Role and relationship checks limited mentors to assigned mentees and PICs to assigned stations. The final platform became a single operational source of truth shaped around the retreat's real rules.
