The unnoticed problem
No one requested an application. The recurring work revealed the need.
Expected attendees appeared on printed sign-in sheets. Walk-ins added details by hand, sometimes incompletely or illegibly. Staff then had to reconcile those records, research attendee and organization identifiers across separate sources, calculate credit, and rebuild the class record needed for reporting. Paper could arrive late or in batches.
Jeremy repeatedly helped with that reconciliation and recognized that the burden was not an isolated inconvenience. It was a repeatable operating problem with multiple roles, rules, source records, and a defined downstream outcome. Rather than wait for a software request, he framed the problem and began designing a safer path.
The opportunity was larger than replacing a clipboard with a form. A useful system had to support attendees, trainers, coordinators, and an administrator while preserving the class record and preparing reliable reporting output.
Product scope
Design backward from the reporting outcome.
The production application supports public check-in, staff access, role-aware navigation, class management, check-in and checkout, unexpected attendees, corrections and bulk actions, source-data matching, attendance and approved-credit calculations, coordinator review, reporting preparation, print and CSV output, audit history, controlled maintenance, and release validation.
That scope reflects a product decision: solve the complete operating path instead of digitizing only its most visible step. Maintained source information reduces repeated lookup. Class status and next actions make handoffs clearer. Credit rules and structured output move calculation and report preparation into the system.
The current supported production platform is Google Apps Script and Google Sheets. Later work involving another data platform is separate and is not presented as a completed migration.
Role-aware design
Give each participant the controls needed for their part of the operation.
Attendees need a focused check-in experience. Trainers need attendance tools and a way to correct class conditions. Coordinators need review, send-back behavior, and reporting preparation. Administrative work requires controlled setup, source synchronization, and maintenance. Combining those responsibilities into one crowded screen would make the system harder to understand and easier to misuse.
From arrival to reporting
Fictionalized operating modelPilot and production correction
Validate beside the known process, then treat defects as evidence.
The organization piloted the application during a live class in July 2026 while retaining the paper process alongside it. That parallel approach protected the only attendance record while testing the actual experience: arrivals, staff responsibilities, record matching, credit rules, output, and recovery when a condition did not fit the expected path.
A live class later exposed a credit-calculation issue involving an unusual session pattern. Jeremy corrected the rule through the release process and validated the change. The important professional claim is not that the first release was flawless. It is that production behavior was observed, corrected, and folded into continuing checks.
Release correction, regression checks, user acceptance testing, performance checks, and kiosk smoke checks are part of the ownership story—not an afterthought to the build.
Result and continuing ownership
A recurring administrative burden became a supported product.
The system removes handwriting interpretation from normal check-in, uses maintained information for much of the attendee and organization matching, calculates credit, and gives coordinators a structured class output. By firsthand estimate, reconciliation and reporting work that could take more than an hour for one class moved to minutes.
Jeremy continues to manage releases, troubleshoot production behavior, validate rules, improve performance and usability, and support the organization as real class conditions reveal new requirements. The case demonstrates proactive discovery, product judgment, custom application design, cautious live validation, and accountability after launch.
Evidence boundaries
What is measured, what is estimated, and what remains private.
The application, release history, live parallel pilot, production correction, and continuing ownership are supported by direct implementation evidence. The approximately 15 classes, staff-role counts, and change from more than an hour to minutes are firsthand estimates and are labeled that way.
A private dashboard count includes scheduled or future work, so it is not used as a completed-class total. No real screenshots are published or lightly blurred. The page does not expose attendee, trainer, certification, organization, identifier, account, class, location, URL, access, or report information. It also does not imply that later migration work replaced the current Apps Script and Sheets production system.