When an event depends on the software.

An event platform has two audiences who need the same facts in different forms. A participant wants to get through the gate, find the right screen and understand what happens next. The staff need to verify access, resolve inconsistencies and keep the event moving.

Ascent brought those workflows into one team-built system. The public source is now an archive, but it still shows the engineering behind participant dashboards, staff administration, submissions, check-ins, rewards and leaderboards.

A QR code is only the visible edge

Scanning a graphic is the easy part to describe. The more important question is whether this staff member is allowed to act on this event, and whether the state they see agrees with the participant’s account.

The retained QR routes check event-scoped access before handing work to the QR service. Around that path sit authentication, participant data and the staff interface. A repeat scan or a stale screen is not simply a UI annoyance when several people are trying to coordinate the same live operation.

The system combines React interfaces, a FastAPI backend, Supabase/PostgreSQL, Redis and storage. These pieces connect public-facing actions to operational state rather than existing as an impressive list of technologies.

The economy behind the leaderboard

Coins introduce another set of expectations. A balance, a transaction history and a ranked list describe related state, but they are not interchangeable views. The retained routes include reservations, disputes and timed surprise-drop operations as well as ordinary balance and leaderboard queries.

That is why cache behavior and administration belong in the same story as the participant screen. Making a leaderboard quick is useful; making it possible to explain and resolve a discrepancy is useful in a different way. The staff need tools for the situation where an ordinary happy-path response is no longer enough.

Submissions and uploads bring similar boundaries: who can submit, which event the object belongs to, and what a staff member can inspect or change. Each workflow turns a small event rule into something the API and interface must agree on.

A platform made by a team

My contribution includes the backend foundation, API and admin workflows, deployment support, and caching and leaderboard behavior. Mirage, the image-processing subsystem, is credited to X-DIABLO-X. Other original contributors and their source history remain part of the record.

That distinction matters. A platform can be a major part of my engineering experience without every component becoming my individual invention. The linked history is more useful than a broad claim of sole ownership.

Keeping the history without reviving the old operation

The screenshot is a capture of the historical frontend. The repository deliberately preserves source, artwork and contribution history while disconnecting operational services. It is not a current hosted event service or a production starter with its old accounts waiting to be reconnected.

Earlier project records contain endpoint, migration, table and attendee counts. I have not turned those dated records into fresh measurements of this filtered archive. The engineering is visible without borrowing a larger number than the present source can establish.

What stays with me is the relationship between the two audiences: every convenient participant interaction creates an operational promise somebody on the event team has to keep.