CASE STUDY

Y&F Event

Mobile App + Self-Hosted API • Access Control

Project Overview

Attendance and access control for events: cryptographically signed tickets, offline decisions at the door, and participant data that never leaves your own server.

Context & Challenge

Event check-in fails in exactly the places events happen: a basement, a marquee, a saturated hall. Cloud-based scanners stop working the moment the network does, and the queue stops with them. Organisers who handle personal data — schools, institutions, companies — also have a second problem: the usual services hold the participant list on someone else's infrastructure.

Client Objectives

• Make a ticket that cannot be forged or usefully duplicated
• Decide at the door without waiting for the network
• Keep the participant list on the organisation's own server
• Give a team roles and limits that are enforced, not just hidden in the interface

UX Research & Architecture

The design starts from the queue, not the dashboard. Door staff need one decision — let this person in, or do not — delivered in under a second, in bad light, one-handed, while a line builds behind. Everything else (manual check-in for disputes, cancelling a scan, entry/exit/re-entry) sits one level down. The organiser's view is the opposite: live counters, attendance curve, flow per door, presence rate per session.

UI Design & Design System

Dark, warm, high contrast: a near-black violet ground crossed by the amber-orange-magenta gradient taken from the logo, set in Inter. The whole icon set — adaptive Android icon with its monochrome layer, round icon, silhouette notification icons, Play Store icon, in-app logos — is derived from a single master file by a reproducible pipeline, so one image changes and everything regenerates.

Development & Technologies

Flutter on Android against a self-hosted PHP API and MariaDB at yandef.com. Event signing keys are encrypted at rest with AES-256-GCM and can be revoked in one gesture, invalidating every ticket issued before and regenerating the rest. The QR payload is 84 characters, uppercase only, which keeps it in alphanumeric mode — a smaller code, read faster, even printed small or shown on a cracked screen. Google Sign-In tokens are verified on the server (signature, issuer, audience, expiry), never on the phone.

Tech Stack: Flutter (Android), self-hosted PHP API, MariaDB, HMAC-SHA256 signed tickets, AES-256-GCM key storage, Google Sign-In verified server-side

Results & Business Value

• Tickets signed with a per-event key: forgery is rejected without a database lookup, duplicates are caught as already checked in
• Doors keep working with no network at all; sync afterwards is idempotent, so nothing is double counted
• Participant data stays on the organisation's own domain, server and database — no third-party account, no quota, no forced migration
• Six roles from owner to observer, enforced server-side, with per-event tokens that can be revoked remotely if a door tablet is lost
• GDPR centre: retention policy per organisation or event, traced access and erasure requests, per-person export, scheduled anonymisation, append-only audit log that masks secrets

How this was measured: The behaviours listed above are properties of the design — a signature that cannot be produced without the server key, a device-side identifier that makes a replayed upload a no-op — not measurements taken after the fact. Attendance figures from a live event will be added here once an organiser authorises publication.

What it does not do

• Online payment is deliberately absent. Ticketing records an amount, a settlement state and a transfer reference; the payment layer can be added without touching the rest.
• Apple and Google Wallet passes are planned. Tickets work today as a displayed or printed QR.
• The automatic e-mail queue and its scheduled task exist; the templates do not yet.
• The badge designer table is in place, the editor is still to build.

Inside the product