Context
Organisers run several events a year, and every one wants its own brand, its own app store listing, its own agenda, sponsors and language. Buying a bespoke app for each event does not scale. Stitching together a registration tool, an app vendor, a badge printer, a networking product and a lead-retrieval supplier scales even worse, because none of them share a record of who the attendee is.
Eventify is our answer: a single platform that an organiser logs into, configures, and ships under their own brand. It now covers registration and ticketing with coupons, check-in, badge printing, a desktop kiosk, exhibitor lead retrieval, attendee matchmaking, session speech-to-text, analytics, an AI support bot and white-label vanity domains. This study is about the platform itself; the AI features have their own studies.
The challenge
Four problems shaped the architecture more than any feature request.
- Multi-tenant white-labelling. One backend serves many organisers and many events. A push notification, an email or an export that reaches the wrong audience is the worst bug the product can have.
- The conference floor. Wi-Fi dies, thousands of people arrive in a thirty-minute window, and staff behave in ways no test plan anticipates.
- Constant change. A speaker is late, a room is swapped, a track is renamed at eight in the morning. Attendees expect the app to know within seconds.
- Feature growth without a rewrite. Matchmaking, transcription and a support bot were added years after the first release. They had to slot in behind the same tenant boundary.
What we built
The platform is three things that talk to each other constantly: the client apps, the organiser admin, and the API that ties them together.
For attendees
- Native iOS and Android apps plus a web app, each built from one codebase and branded per tenant.
- Personal agenda with reminders, RSVP, session check-in and calendar export.
- Networking: attendee search, meeting requests, QR business-card exchange and AI matchmaking.
- Session Q&A, polls, surveys, community feed, and offline mode for the parts of the venue where the signal gives up.
For organisers
- One admin console for every event under the account: forms, tickets, coupons, agenda, speakers, sponsors, exhibitors, groups and permissions.
- Bulk imports, email templates per event, push notifications by group or track, and an analytics dashboard.
- Badge templates, bulk PDF printing and the self-service kiosk.
- White-label vanity domains so the web experience lives on the organiser's own hostname.
For exhibitors
- Lead retrieval by scanning attendee badges, with notes and export, scoped to the exhibitor's own booth.
Architecture
The clients are deliberately thin on business logic. The API resolves the tenant and event from the token once, attaches that scope to the request, and every service and every query inherits it. The realtime layer is the exception to the request model: during an event window, agenda and announcement changes are fanned out over WebSockets to connected apps rather than waiting for the next poll.
Key decisions
1. Native apps, thin clients
Swift and Kotlin for the mobile apps, React for the web and admin. Branding, feature flags and content all come from configuration, so a new tenant means a new build configuration and store listing, not new code.
2. Tenant scope is resolved once and enforced twice
A notification scheduled for one conference must never reach an attendee of another event on the same backend. Each event has its own push topic, device tokens are keyed by tenant and event, and a server-side guard rejects any send that is not scoped. The data layer repeats the check: there is no code path that queries attendees without a tenant filter, and the test suite includes cases that try to cross tenants.
3. Optimistic check-in with idempotency keys
The first scanner confirmed with the server before showing "checked in". It worked in the office and queued to death at a large conference when everyone arrived at once. The rewrite checks in locally, reconciles in the background and sends a client-generated idempotency key so duplicate scans never double-count. The third iteration works fully offline and catches up on reconnect. The kiosk study covers this in detail.
4. Realtime only where it earns its keep
Pull-on-foreground was fine for sponsor listings and useless for agenda changes. WebSocket fan-out is switched on per tenant for the duration of an event and switched off afterwards, which keeps infrastructure cost proportional to live events rather than registered ones.
5. AI as services behind the same boundary
Matchmaking, transcription and the support bot are separate services that call the API like any other client, with the same tenant scope. That meant no changes to the core when they arrived, and it means an organiser can switch any of them off. Each has an evaluation set that runs before a model or prompt change ships; see fine-tuning and evals for how we approach that in client work.
Outcome
An organiser with a small events team can launch a fully branded app and web experience in days rather than commissioning a bespoke build. Check-in and badge printing keep working when the venue network fails. Agenda changes reach attendees while the room is still being swapped. AI features were added years into the product's life without touching the tenant model, and the platform keeps shipping new features regularly.
The lesson we repeat most often: the hardest event-tech bugs are not in the code but in day-of behaviour. People do things at conferences they never do in QA, so every feature gets tested at a live event before we call it finished.
What this means for you
If you are building a multi-tenant product with a serious mobile experience, white-labelling, offline tolerance or AI add-ons, this is the shape we would propose. A short discovery sprint is usually enough to decide whether to license Eventify as a white-label platform, extend it, or build something of your own on the same patterns. Either way, the tenant boundary comes first and the features come second.