// INSIGHTS
Building an Event App for a 2,000-Delegate Conference
6 min read
Two thousand delegates is the point where an event app stops being a nice extra and starts carrying operational load. Agendas change at 9pm. Three halls run at once. Half the room is on a mid-range Android handset with two bars of signal. The app has to hold. This is the build sequence we use, the modules that earn their place, and the parts that break when nobody plans for them.
What actually changes above a thousand people
At 250 delegates, most problems are solved by walking across the room. A volunteer finds the person, fixes the badge, points them at the right hall. At 2,000 that stops working. The floor team cannot reach everyone, the help desk becomes the bottleneck, and every small friction is multiplied by two thousand. The app has to absorb work that humans used to absorb.
Concurrency is the first wall, and it is spiky rather than steady. Delegates do not open the app evenly across eight hours. They open it in the ninety seconds after a keynote ends, when the whole hall reaches for a phone at once to find the next room. Load tests should model that shape specifically: a flat baseline with four or five sharp peaks that line up with the agenda. An API that comfortably handles 2,000 requests spread across a minute can still fall over when 1,400 of them land in six seconds.
The second wall is content freshness. On a two-day conference with 60 sessions, the agenda will change. A speaker misses a flight. A hall gets swapped at 7am. If an agenda change needs an app store release, you have already lost. Everything that can change must be server-driven and cached locally, with a version stamp the app checks on resume. The binary should be a shell. The content lives behind an API that an organiser can edit from a laptop in the green room.
The numbers we design against
Modules that earn their place
Personal agenda with clash detection
Delegates build their own schedule and the app flags overlapping sessions before they commit. The same data drives seat counts for halls with limited capacity.
Offline-first session data
Agenda, speakers, floor plans and the delegate's own QR code render with no network at all. Only writes queue for sync, which keeps the app usable in a basement ballroom.
QR session scanning
Scanners at hall doors record attendance in about a second per delegate. That record feeds attendance certificates, sponsor reports and the points economy if you run one.
Search that tolerates name spellings
Delegate and speaker search matches transliteration variants and partial names. Strict exact-match search fails constantly against a list of two thousand Indian names.
A twelve-week build sequence
Weeks 1-2: freeze the data contract
Agree the field schema for delegates, sessions, speakers and sponsors. Most late-stage delays trace back to a registration export that changed shape in week nine.
Weeks 3-7: build the spine
Navigation, authentication, agenda and the offline cache go in first. Gamification, matchmaking and feedback layer on top of something that already works.
Weeks 8-10: real content and store submission
Load the actual agenda, not placeholders. Both iOS and Android builds go to review with a week of slack for a rejection and resubmission.
Weeks 11-12: rehearse on site
Walk the venue with the real scanners on the real network. Run a load test shaped like the agenda, then a full dry run with the floor team and the help desk.
What usually goes wrong
The most common failure is not technical. It is the delegate list arriving four days before the event, split across three spreadsheets, with duplicate email addresses and phone numbers in five different formats. The app cannot authenticate anyone if identity is ambiguous, and cleaning 2,000 rows by hand at that stage is a two-day job nobody has budgeted. Lock the export format in week two and take a test file every fortnight, even if it only has 40 rows in it.
The second is venue connectivity that was specified for the AV team rather than for two thousand phones. Ballroom Wi-Fi is routinely oversubscribed by a factor of ten, and the access points nearest the stage saturate first. Design as though the network fails, because at some point it will. The third is late scope. A feature added in week eleven costs an app store review cycle, and that cycle sits directly on top of your event date. After week ten, the honest answer to a new feature request is that it goes in the web version or it goes in next year.
Common questions
Do we need native apps, or will a web app do?
A web app is cheaper, has no store review cycle, and works fine for agenda browsing. It cannot do reliable push notifications on iOS, true offline mode, or fast camera-based QR scanning. If your event depends on any of those three, ship native to both stores and keep a web fallback for people who will not install anything.
How late can we change the agenda?
Up to and during the event, provided the agenda is server-driven. Changes propagate on next app resume, typically within seconds. What cannot change late is anything compiled into the binary, such as new screen types, so those decisions freeze around week ten.
What drives the cost of a build like this?
Module count and content-load effort, far more than delegate headcount. A single-track app for 2,000 people costs less than a multi-cohort app with gamification and matchmaking for 400. Data cleanup, translation and on-site support are the line items most often left out of the first estimate.
Planning a conference above a thousand delegates
Send us your delegate count, agenda shape and event date, and we will map a build sequence against it.
