Photo: Google Gemini · AI-generated
Most software gets a second chance. If something breaks on Tuesday, you fix it and ship on Wednesday.
Event software does not work like that. The show runs for three days and then the stand comes down. Whatever happened, happened.
That single fact — plus the radio environment you are deploying into — is what makes on-site experience work harder than it looks from a brief.
The floor is the hostile part
A trade show hall is one of the worst radio environments in normal commercial use.
Every exhibitor has brought their own WiFi. Many have brought beacons. Thousands of visitors are carrying phones that are all scanning, advertising and connecting. The 2.4 GHz band, which BLE shares with a lot of WiFi traffic, is saturated in a way it never is during a calm office test.
We built native iOS and iPadOS trade show apps for a German digital agency and their automotive client — quizzes and competitions on booth tablets, using BLE and WiFi for proximity detection, multi-device sync and location-aware content, with results reported back live so the client could see engagement as it happened.
The agency’s brief named the real constraint up front: proximity and connectivity tech reliable enough for a crowded RF floor. That is the requirement. The features are the easy half.
Design for the bad reading, not the demo
The mistake is treating proximity as a fact. It is not. It is a noisy estimate that degrades exactly when the hall is busiest — which is also when it matters most.
So the useful engineering is defensive. Treat a proximity signal as a hint that can be wrong rather than a trigger you obey. Never let a dropped connection strand a visitor mid-interaction. Keep the experience working locally, and treat sync as something that catches up rather than something the interaction waits for. Make live reporting tolerant of gaps, so a lost minute of connectivity does not corrupt the numbers the client is watching.
None of that is exotic. It is just the opposite of how a demo is usually built, and a demo is what most of these projects are validated against.
You cannot patch a trade show
Ordinary release discipline assumes you can follow up. Here the deadline is physical, and the window is the show.
That changes where the effort goes. Testing has to happen in conditions resembling the real floor rather than a quiet office. The build needs an on-site failure mode a booth attendant can actually use — a way to keep the activation running when something misbehaves, without a developer present. And whatever is shipped has to be the version that works, because there is no second sprint before the doors open.
The upside is that the constraint is honest. Everyone can see the date.
Agency-grade does not mean maximal
It is tempting to conclude from all this that agency work always calls for sophisticated native builds. It does not, and assuming so wastes the client’s money.
For the same audience we also built an industrial calculator app for a regional agency — volume, pressure, mass and similar formulas for field engineers. That one is Cordova, one shared codebase wrapped for iOS and Android, because the job was reliable offline formulas in a technician’s pocket. Two native codebases would have doubled the maintenance for no benefit the user would ever notice.
Both are white-label delivery for a digital agency. One needed deep native work because the radio environment demanded it. One needed the pragmatic option because nothing about it demanded more. Knowing which is which is most of the value a delivery partner brings.
What both share is the part that is not technical: the end client only ever sees the agency. When the stand is busy and the tablets are working, that is the agency’s win. Which is exactly how it should read — as long as somebody planned for the floor.
If you are an agency with an on-site activation and a fixed date, we should talk.