Virtual exhibition: the app loses visitors at the entrance
A visitor opens the virtual exhibition app exactly when the exposition starts.
The first screen should appear within a couple of seconds, but instead a splash screen spins: the booth catalog, schedule, and exhibitor cards are pulled from the server as a single block while everything loads — from covers to the list of talks.
Visitor drop-off at the entrance is the most expensive possible here: someone who doesn't make it past the splash screen won't reach a single booth or leave a single contact.
The second loss is quieter and therefore more dangerous. The guest did get inside, but the booth cards are empty, images didn't load, and the booth stream cuts off mid-sentence.
Slow booth loading reads as a non-working exhibitor: the visitor decides the booth is empty and moves to the neighboring one. Winning that attention back by reopening the app is almost impossible — a second visit rarely happens.
Peak load at an exhibition is not an abstraction: the audience arrives in waves — a burst in the first minutes after opening, then spikes during key talks and giveaways.
A solution designed for average traffic breaks precisely during those minutes, and the one who pays for the downtime is not the venue but the exhibitor who was waiting for visitors at their booth.
We'll break down how this is addressed: where failure boundaries are set in an exhibition app, what is preloaded in advance, and how the entrance stops depending on the peak.
Booth navigation, schedule, and contact collection
The first screen determines whether the visitor reaches an exhibitor at all. We bring the exhibition hall map to the top and build it on Mapbox: a vector layer with search by booth number, a route from the entrance, and a “I am here” marker.
We cache the map on first launch — booth navigation works in a hall where the network is overloaded or drops. Time to the first booth falls from minutes of wandering by signs to 30–60 seconds.
The event schedule in the app is not a copy of the website program but a personal plan. The participant selects topics, the app builds a selection, sets local reminders, and rebuilds the route with buffer time for moving between sessions.
The program updates via background sync: if the speaker changes, the badge on screen is already correct.
Visitor contact collection is completed with one tap: a code at the booth, consent confirmation, and two-way business card exchange.
Records are stored locally and sent to the corporate contact database in batches when the network appears — the exhibitor receives a list noting where and when the conversation took place, not a stack of paper cards.
The entrance peak is the main risk: the hall opens, and hundreds of people simultaneously open the map and schedule. We serve hot data from cache, while check-ins and requests are queued and sent as the channel frees up.
The app remains responsive, and the share of visitors reaching an exhibitor does not drop in the first minutes.
Operating modes: offline map, hybrid, web version
The choice between an offline map, hybrid mode, and web version is not a matter of taste. It is determined by the venue, connection stability, and how often the program changes during the event days.
In a pavilion with thick walls and an overloaded access point, the network drops precisely at rush hour, while at an open urban venue a visitor is more likely to open a link than install an app.
We assemble the map base for the offline layer from open OpenStreetMap data and slice it into tiles in advance — the app does not go online for the map and works in airplane mode.
Then all that remains is to choose from three options, and each has its own maintenance cost and scenarios it does not cover.
| Option | When it fits | Limitations |
|---|---|---|
| Offline map inside the app | A venue without stable connectivity where the route to a booth matters | The program and booths update only with a new build; the map takes up space on the device; visit statistics arrive with a delay |
| Hybrid: offline core plus online layer | The program changes during the event, and some halls have no connectivity | Requires data merge rules and clear behavior when versions diverge; maintenance is more expensive |
| Web version via link | A short event, audience comes from different devices | No offline mode or notifications; results depend on the visitor's network and browser |
In practice, hybrid more often wins, but only if a source of truth for the schedule and hall map is designated in advance. Without this, the offline layer and the server diverge, and the visitor sees a canceled event on their screen.
Implementation stages: from exposition audit to handover
The work proceeds in waves, and each ends with an artifact that can be checked before the next starts.
The order is not accidental: until it is clear what exactly the exposition shows and how often it changes, the app turns into a set of static screens that are already outdated by opening day.
- Exhibition content audit. Inventory of booths, media, schedule, hall maps, and connections to the registration system. Result — a map of sections and a table of data sources with update frequency.
- Flow diagram and prototype. We determine what is updated through the admin panel without a rebuild, what is cached on the device, and how the screen behaves when connectivity drops in the pavilion. Result — an agreed architecture and a clickable prototype of key scenarios.
- Core build. Hall navigation, schedule, notifications, entry by ticket or invitation, and visit analytics. Result — a working build on the test environment, not a mockup.
- App load testing. Run through the scenario of simultaneous visitor entry at opening time, check degradation on a weak network and behavior when a service is unavailable. Result — a report with bottlenecks and fixes before public launch.
- Pilot on real traffic. A closed run with a group of visitors: we look at time to first screen, the share of successful entries, and the number of failures. Result — fixes based on actual behavior, not assumptions.
- Exhibition app implementation. Publication in app stores, passing reviews, and arranging engineer on-call for the event days.
- Project handover to the client. Repository, access, content update procedures, and instructions for releasing a new version by your team — without our ongoing support.
We fix the acceptance criterion for each stage in advance: a stage is not considered closed until the artifact is accepted. This eliminates the situation where, by opening day, it turns out that the schedule in the app does not match the venue.
Configurations, diagrams, and regulations at handover
The handover package is not an archive with source code but a set of documents and settings by which a third-party team deploys the staging environment, releases an update, and changes content without us.
We assemble it in parallel with development: if the integration diagram can only be reconstructed from an engineer's memory, the project is not considered delivered.
- Environment configurations. Service addresses, access keys, and build parameters are moved out of the code into separate files — test and production environments are switched by changing configuration, not by editing source code.
- Exhibition integration diagram. Direction and format of exchange with the registration and ticketing system, external CRM, streaming player, and analytics; separately — behavior when each service is unavailable.
- Visitor data access rights. Role matrix: the organizer sees aggregated statistics, the booth staff sees only their own guests, and personal data export is a separate role with an operations log and retention period.
- Content update procedures. What changes through the admin panel without releasing a new app version (schedule, booths, video, presentations), and what requires a rebuild and testing on the test environment.
- App documentation. Architecture and storage description, internal API specification, build instructions, signing, and publication in app stores.
- Release and rollback procedures. Branch workflow, mandatory checks on critical paths, acceptance, and rollback to the previous stable build.
- Project handover and support. Ownership of developer and service accounts is transferred to the client, and the warranty window and terms of further support are fixed.
After handover, you can develop the app with your own team or return to us for support — access and knowledge remain with you.
Case study: a multi-hall exposition and peak entrances
Initial situation
The operator of the exhibition venue ExpoForum came with a classic pain point: a visitor downloaded the app in advance but got lost between halls on site.
The ticket, map, and participant list lived in different sections, so only about half of those who opened the map reached the desired booth.
Measurements from the previous event provided a baseline for comparison: reach rate — 52%, support requests — about a hundred per day, mostly “where am I and how do I get there.”
What was changed
We rebuilt the visitor journey: entry by code directly from the lock screen, a map tied to beacons in the halls, and a route built from the current point to the selected booth.
A booth is checked in with one tap — the check-in immediately goes into the organizer's statistics, and the visitor is shown nearby expositions on the same topic.
The support load was reduced with in-app hints: schedule, entrances, cloakroom, and transitions between pavilions. Two operators remained on shift instead of eight, and they handled complex cases rather than navigation.
What the result was
Time from entrance to the first booth was cut in half, and reach rate grew from 52% to 79% — almost everyone who opened the map reached an exhibitor. Support requests dropped by about five times, and the share of navigation questions fell from most to only a few.
The exhibition mobile app case study produced another result: before and after metrics are calculated by a single event — a scan at the booth. The organizer compares events with each other and sees exactly where the visitor is lost.
What to do if the app is already released and the exposition changes
If the app is already installed by visitors and the exposition changes, re-releasing the build is the worst available path.
Stores review the release, some guests will update weeks later, some won't update at all, and people with different versions will end up side by side at the venue. For an exhibition that lasts several days, this means divergent navigation and lost booths.
The working solution is to move the exposition description out of the build and onto the server. On launch, the app requests configuration: the list of halls, passage map, points of interest, session schedule, and content binding to booths.
As long as the data model is versioned and the client can read both the current and previous schema, adding a hall or moving a talk time does not require a new build.
A separate task is migration to the new hall structure when the venue changes its layout. Old identifiers are matched to new ones, navigation receives transition rules, and favorites, route, and quest progress are transferred to current points.
The guest does not notice the schema change: they open the app and see the same route, just through the new halls.
Updating the exposition without a re-release relies on exhibition content management: the organizer edits booths, speakers, and timing themselves, while caching rules determine when the client fetches fresh data and when it works with a saved copy — connectivity at the venue is often unstable.
Modifying the existing app is needed only if a new content type or native module appears: then a release is inevitable, but it is rolled out gradually, with flags and crash monitoring.
The review begins with an audit of the current build: what is already parameterized and what is hardcoded. Then we plan changes so that installed versions continue to work.
Limitations: weak connectivity, old devices, offline
Pavilions with concrete walls and overloaded airwaves are common: a guest approaches a booth, and the network won't even serve a page.
That is why the logic is built from the offline scenario: the participant catalog, map, and booth materials are stored locally, while visitor actions are queued and sent to the server as soon as the channel returns.
The guest does not notice the substitution, and registrations and contacts are not lost during an outage.
We fix the lower device threshold before development: OS version, memory capacity, and the age of devices from the real visitor fleet, not just new flagships.
Heavy 3D scenes on weak hardware are replaced with static panoramas — the app does not crash but adapts the presentation to the device's capabilities.
We collect visitor data to a minimum — only what is needed for registration and transferring a contact to a participant. Access tokens are stored in the system's secure storage, transmission goes over an encrypted channel, and only anonymized cache remains on the device.
What will the app show if connectivity is lost right at the booth?
The same program and materials — they are already in the cache. The screen indicates that some data will update later, while check-ins and requests are sent to the server after the channel is restored.
Will the app work on devices that are several years old?
Yes, if the device meets the lower threshold fixed at the start. For weak configurations, lightweight booth display modes are predefined.
How is visitor data protected?
We collect a minimum of fields, encrypt transmission, and restrict employee access by role. At the client's request, data is deleted together with the exhibition.
Let's discuss the task: we'll assemble a plan and estimate for your exposition
So that the development timeline estimate is based on facts rather than guesses, we need a minimum of input data — usually one conversation and access to materials are enough. Below is a list of what speeds up the calculation the most.
- Exposition map: floor plan of halls and booths, points of interest, transition logic between them — in vectors, a table, or even a hand-drawn sketch.
- Content: exhibitor descriptions, media, streaming links, and requirements for languages and event schedule.
- Visitor scenario: how a person enters the app, and what we consider the target action — booth view, request, or personal meeting.
- Integrations: registration system, participant catalog, request tracking — with access to the test environment and sample responses.
- Platforms and conditions: priority devices, whether offline mode is needed for pavilions with weak signal, and entry requirements.
- Access and approvals: accounts for building and publishing, who approves mockups, and rules for handling personal data.
- Constraints: exhibition opening date and program events that cannot be moved.
On this basis, we return with a work plan for the exhibition app: stages, their duration, team composition, and acceptance points at each step.
If the plan works for you, we discuss app development and kick off the exhibition project — describe the task, and we will return with an estimate and a proposed course of action.