The event floor stack: building interactive experiences that survive a congress

If you run production at an event agency, you know the shape of this problem. The client has bought an interactive idea for their stand. A touchscreen, a photo experience, some kind of engagement measurement. You have sold it, you have a date, and now somebody has to make it work on a stand in a hall you have never set foot in, on hardware that arrives on build up day, on a network you do not control.

I am the somebody, for a handful of agencies. I have built the interactive layer for Johnson & Johnson Medical at EADV and WCLC, and for GSK at ECCMID. This piece is about what breaks on a real congress floor and what I do so it does not. If you subcontract this kind of work, it is a checklist for what to ask whoever you hand it to.

What actually breaks

Not the code, mostly. The environment.

The network goes. Congress Wi Fi is shared with several thousand people, all of them on their phones. It is slow by mid morning and gone by the afternoon keynote. Wired connections are promised and then turn up as a single port on the wrong side of the stand. Anything that needs a server to answer before it can draw the next screen will freeze in front of a visitor. That is the failure the client remembers.

The data is sensitive. The people on the stand are doctors. Pharma clients have compliance teams who will ask, in writing, where every photo and every interaction goes. If the answer involves a cloud bucket in another jurisdiction, you have a meeting you do not want, a week before the show.

The content changes after you have shipped. Legal swaps a claim. Medical affairs pulls a slide. The client wants the logo on the idle screen to be the other logo. This happens after the build is signed off, often after the doors have opened, and the request comes from someone standing next to the screen.

Nobody technical is on the stand. The stand build crew plugs things in. The client's team are marketers and medical people. If the fix needs a laptop, a terminal and someone who knows the codebase, the screen stays broken until that person can get there.

The date does not move. The congress opens when it opens. There is no soft launch and no "we'll patch it Monday". You are either working on the floor at nine on the first morning or you are the story everyone tells about the stand.

Every one of these is predictable. So every one of them is a design decision, made before the first line of code.

Offline first, not offline tolerant

There is a difference. Offline tolerant means the app copes for a bit if the network drops. Offline first means the network is optional. Everything the visitor can do, they can do with the cable pulled out. The network, when it exists, is used to send things elsewhere. It is never in the path of the experience.

Concretely, for the photo mosaic I built for J&J Medical at EADV:

• The photo is captured in the browser on the kiosk, using WebRTC. No upload step.
• It is written to a local database on the kiosk, and the mosaic on the 4K wall picks it up from there. A 25 by 14 grid, 350 photos to a page, new pages as they fill, rotating every 30 seconds. The wall never asks a server for anything.
• The visitor types their email on an on screen keyboard and the photo goes into a queue. The email leaves when there is a connection for it to leave on. If that is in twenty minutes, fine. The visitor already saw their photo on the wall, which is the part they came for.
• Analytics are recorded locally and replayed to the server when the network returns.

The result was 665 photos in the first days of the congress and zero downtime. Not because the venue network behaved. Because it did not matter whether it did.

EventScope, the engagement analytics platform for the same team at the same congress, took the same principle to a fleet. Twenty-plus devices across the stand, each running its own detection, each with its own local store. They sync to the dashboard server in batches, and if the sync fails they back off and try again later. The demo I gave the client before the show was simple: I pulled the network cable, the devices carried on counting, I plugged it back in, and the dashboard caught up. Once a client has watched that, the venue network stops being a risk in their head.

The GSK vaccines navigator, a 55-inch portrait touchscreen, was fully self contained. All content on the machine. Engagement events cached locally and replayed when a connection appeared. And for a J&J kiosk at WCLC I went further and put the analytics dashboard on the device too, laid out for an iPad, with a CSV export, so the medical affairs team could read the day's numbers on the stand with no network at all.

The question to ask your subcontractor is not "does it work offline?" Everyone says yes to that. Ask: "what happens, exactly, when I pull the cable at 2pm on day two?" You want a specific answer for every feature.

GDPR handled on the device, not in a policy

Pharma compliance teams are not being difficult. They are asking the right question and they need an answer they can write down. The cleanest answer is architectural: the personal data does not leave the stand, so there is nothing to ask about.

For EventScope this meant on device inference. Each unit runs its detection models locally and produces counts and timestamps. Dwell time in a zone, number of people, interaction events. What crosses the wire to the dashboard is numbers. Never an image, not even to my own server. Nobody is tracked between zones, nobody is re identified. And the data has a 30 day retention that cleans up after itself, so there is no long term dataset of doctors' movements sitting on a server waiting to become someone's problem.

For the photobooth, the photo obviously exists. It stays on the kiosk and it goes to one place: the inbox of the person in it, because they asked for it. Nothing is posted anywhere and nothing is copied off to a third party service to be processed.

For the touchscreens, the analytics are about content, not people. Which pillar was opened, how long on each screen, whether the visitor reached the end. No identity, no faces, no accounts.

None of this is hard. It just has to be decided at the start. Retrofitting privacy into a system that was built to send everything to a cloud API is where projects lose two weeks a month before the show.

Same day changes are normal, so build for them

Content will change after sign off. Treat that as a requirement, not a change request.

The way I handle it is to keep content out of the code. On the GSK navigator, each of the five topics hands off to its own infographic, loaded separately from the main hub. Swapping a slide or a claim is swapping a file. The hub does not need to be rebuilt or even restarted. The WCLC kiosk is five presentation tracks of image and video slides, and a track is a folder.

The second half is making the change deployable by someone standing at the screen. No app store, no build pipeline that needs the internet, no SSH. A file on a USB stick, or an admin screen behind a tap and hold, and the content is live. I am reachable throughout the congress, but the goal is that most changes do not need me.

Ask your subcontractor how a slide gets changed on the day, in steps. If the answer starts with "we'd push a new build", that is a build that will not be changed on the day.

The stand has to look after itself

A congress stand runs for three or four days with no one minding the screens. Things that would be minor in an office are fatal here, because nobody notices for an hour.

So every kiosk I build has a watchdog. The GSK navigator shows a branded "what next?" prompt after 90 seconds of inactivity and resets to the attract loop, so the next visitor never walks up to the previous visitor's half read screen. It also monitors the embedded infographics, so a visitor left inside one does not strand the kiosk there. The WCLC kiosk resets to the menu after two minutes. EventScope devices provision themselves: plug one in, it finds the server, registers and starts reporting. The stand build crew installs them without a laptop.

The photobooth accepts a new photo without interrupting the wall. The mosaic keeps rotating and the new photo slots in on the next pass. A crash in the capture flow, if one ever happened, would not take the display down with it. That separation is deliberate.

The test for all of this is boring. Leave it running on the real hardware for a day, do not touch it, and see what state it is in. I do this before it ships. It finds things that no amount of testing on a laptop finds.

The deadline

Everything above is what makes the deadline survivable. If the network can fail, the data stays put, content can change and the stand looks after itself, then opening morning is a formality rather than a gamble.

The process side I have written up separately in Anatomy of a fixed scope build. The short version: a few days of deciding before any building, three milestones with a working demo at each one, the riskiest piece first, and a week in hand at the end for the things that only show up in the actual room. I am on site for build up and for opening morning, because that is when things break. For the rest of the congress I am on call, which on a well built stand means checking a dashboard and going back to what I was doing.

The measure I care about is that the same client team came back. Four builds in a year for the same medical team. Repeat work from a pharma medical team is the only review that means anything in this business.

If you have a stand to build for

I do this at fixed scope and fixed price, so there is no drift for you or your client. Touchscreen presentations, photo and interactive experiences, engagement analytics across a stand, and adapting a previous build for the next event at a lower rate.

Every build starts with a scoping sprint. One week, £1,950 + VAT, and you get a written spec, the architecture, a delivery plan and a fixed price quote. If we go ahead with the build, the full amount is credited against it. If we do not, everything the week produced is yours to take elsewhere.