Patrianara Attendance App

Community teams often record attendance by hand, then build participation summaries after the event. Patrianara explored a shared attendance state with a leaderboard so organizers and members could see progress during the program.

Problem

Manual attendance creates repeated entry work and delays participation feedback. A community also needs clear rules before a leaderboard can represent contribution without distorting member behavior.

Role and scope

I owned product and engineering delivery. I planned sprints with the operations team, turned attendance and leaderboard needs into release scope, coordinated the Next.js, Firebase, and Supabase work, released the features, and wrote the handover notes.

Process and decisions

The product connected an attendance event to a shared member record and leaderboard state. The delivery process moved from scope and sprint planning through release and handover.

Firebase and Supabase both appear in the implementation, but I no longer have the architecture notes that explain the split. Before extending the product, I would choose one system of record and document why the second service remains.

Release and handover

I took the attendance and leaderboard flow through planning, release, and operations handover. The handover covered feature behavior, ownership, and the next maintenance steps.

I no longer have a deployable build or product screenshot, so this page uses a process cover and hides the external link. I also lack member counts, event totals, and time-saved data, so I leave those outcomes unstated.

Limits

I would not restart Patrianara without recovering the schema, attendance rules, and privacy model. A new release also needs screenshots, usage logs, and feedback from the operations team.