Chapter 1. Turning a Service Initiative into a Product
CARA began as a self-initiated volunteer contribution for a church catechism retreat. I noticed that the committee was coordinating participant records, schedules, activities, and event-day responsibilities across several disconnected channels. A conventional event landing page would not solve that operational fragmentation. I therefore framed the initiative as a working product that could support the retreat before, during, and after the event. The result needed to remain simple for participants while giving the committee enough structure to operate confidently.
I took responsibility for the product framing, application architecture, database design, backend development, responsive frontend, and deployment preparation. The platform had to serve participants, mentors, game coordinators, committee members, and administrators without exposing the same controls to every role. Each workflow was translated from the committee's real process instead of being added as an isolated feature. This made the project less about building pages and more about defining how the event should move from one state to another. It also established a single source of truth for the rest of the system.
Chapter 2. Connecting Identity with Attendance
Registered users entered through a lightweight phone-number flow and received a personal digital ticket. Each ticket contained a unique QR identity that connected the participant profile with on-site operations. This avoided creating separate records for registration and attendance. The mobile experience kept the process approachable for participants who only needed quick access during the retreat. Sensitive operational controls remained outside the participant-facing area.
The same QR identity supported the main retreat check-in and attendance for individual rundown sessions. Database constraints prevented duplicate attendance from being recorded for the same participant and activity. Mentors received a more restricted scanner that only accepted QR codes belonging to their assigned mentees. Committee members who logged into the Panitia Area could then review attendance through a wider monitoring interface. This connected fast mobile capture in the field with authenticated operational oversight.
Chapter 3. Making the Rundown Drive the Experience
The retreat rundown became the central navigation layer for the participant experience. It organized the multi-day schedule while also showing attendance status for sessions that required tracking. Participants could save personal notes without leaving the context of a specific activity. Links to devotional material, the Bible quiz, games, and evaluation appeared beside the relevant agenda items. The schedule therefore acted as an interactive event guide rather than a static timetable.
Access to those resources followed the timing of the real event. A resource could open automatically at its scheduled time, be opened manually by an administrator, or remain explicitly locked. This allowed the committee to respond when the physical schedule moved earlier or later than planned. Authorized committee members could request temporary early access through reauthentication without changing access for every participant. The approach kept content release predictable while preserving operational flexibility.
Chapter 4. Preserving Quiz Progress and Fair Results
The Bible quiz contained fifty active questions and allowed each participant up to two attempts. Answers were autosaved so a refresh, interrupted connection, or new login would not erase in-progress work. The server validated that every active question had a valid answer before accepting a submission. Transactional writes and participant-level locking protected the attempt number from becoming inconsistent. Automatic scoring then produced a result without requiring manual correction by the committee.
The operational view separated participants who had not started, were still answering, or had already submitted. Committee members could inspect progress without accessing or changing the participant's mobile form. The leaderboard compared the best completed attempt from each participant. When two scores were equal, the earlier submission time became the tie-breaker. This made both the participant experience and the ranking logic transparent.
Chapter 5. Translating a Physical Game into Software
Baggage Relay was the most complex part of the platform because it began as a physical team activity rather than a digital workflow. The game involved three teams, six sequential stations, station-specific PICs and guards, equipment requirements, and rank-based scoring. Each team also selected physical baggage items that offered different bonus values. Those items had to be carried through the journey and could be released or broken as the game progressed. I modeled these rules directly so the software reflected what was happening on the field.
Participants could see their team, fellow members, current baggage, station instructions, and overall progress from a mobile interface. Each baggage item was tracked independently instead of being stored as a single team total. That allowed the application to distinguish items that remained active, were deliberately released, or were broken after a violation. The point value of each choice stayed visible so teams could understand the trade-off between a larger potential bonus and greater difficulty. This turned the participant page into both a game guide and a live representation of team state.
Keeping progression and scoring consistent
The scoring workflow enforced the order of the physical game instead of trusting each station to coordinate manually. The first station could not be finalized until every team had confirmed its initial baggage selection. Later stations remained unavailable until all three teams had received final scores for the previous stage. Each PIC could submit results only for the station assigned to their account. These controls kept one delayed or incorrect input from silently moving the entire game forward.
Final standings combined rank-based game points, bonuses from baggage still being carried, and penalties recorded during play. Updating a score could also change baggage status or create a penalty record, so those operations were committed in one database transaction. The leaderboard was calculated from finalized records rather than manually maintained totals. Participants and committee members could therefore see how every component contributed to the result. This made live standings easier to trust and reduced the risk of partial updates during the event.
Chapter 6. Turning Feedback into Usable Insight
The evaluation flow covered both the catechism program and the retreat experience. Participants answered structured questions, selected an overall rating, and provided open-ended feedback from their mobile devices. Conditional fields appeared when an answer required additional context. Minimum meaningful-text validation discouraged responses made only from whitespace or very short filler. A unique database rule limited each participant to one completed evaluation.
The committee dashboard transformed those responses into completion metrics and interpretable summaries. It separated participant and committee responses, calculated the average rating, and displayed distributions for agreement and multiple-choice questions. Written answers remained available for qualitative review instead of being reduced to charts. Administrators could also export the dataset for follow-up outside the application. This extended CARA from event-day coordination into post-event learning.
Chapter 7. Building for Real Operational Use
I built CARA as a server-rendered PHP and MySQL application with a custom front controller and responsive interfaces. Its data model connected users, mentor assignments, rundown sessions, attendance, quiz attempts, game teams, baggage, equipment, scores, penalties, and evaluations. Prepared statements and output escaping protected normal data access and rendering paths. CSRF validation guarded state-changing requests made from authenticated areas. Database constraints and transactions protected workflows that depended on several records changing together.
Role checks separated participant, mentor, committee, PIC, and administrator responsibilities throughout the application. Relationship-based authorization went further by limiting mentors to assigned mentees and PICs to assigned game stations. Idempotent imports and seed scripts made participant and event data safer to revise as plans changed. The final platform brought identity, schedule, activities, live operations, and feedback into one operational source of truth. What began as a volunteer initiative ultimately became a complete event system shaped around the real rules of the retreat.
