Planning an event? Call 0141 280 9337 Email us Send event details
Event WiFi ScotlandOperated by ErskineTech Ltd
Home / Guides / Project example

Local network project example

Making an event app work at local network speed.

For Inverarity Morton’s Hauf an’ a Hauf at Leith Theatre, we rebuilt a local-ready version of the event app so devices on site did not need to send every request over the external internet connection.

Updated 18 July 20265 minute read
Discuss an event app or networkTemporary internet options

The useful idea

Internet speed and local network speed are different. When content is hosted inside the event network, connected devices can reach it directly without using Starlink, 4G, 5G or venue broadband for every page load.

The challenge

Event apps and web guides are often designed as ordinary internet services. Every device requests pages, images and data from a remote server. At a temporary event, that means the app competes with card payments, staff systems, cloud tills and other traffic for the same external connection.

For Hauf an’ a Hauf, Inverarity Morton’s immersive beer and whisky showcase at Leith Theatre, the app needed to remain quick and useful on site. The sensible approach was not simply to demand more internet bandwidth; it was to remove unnecessary traffic from the internet path.

The local-ready solution

We rebuilt a version of the app that could be served from a system inside the event network. Once a device joined the event Wi-Fi, requests for the local content travelled across the local network rather than leaving the venue and returning through the external connection.

Phone or tabletJoins the event Wi-Fi
→
Local event appContent served inside the network
→
External internetUsed only where genuinely needed

Why this matters

  • Local pages can load at the speed of the event network rather than the shared backhaul.
  • Repeated page and image requests do not consume external bandwidth unnecessarily.
  • More of the internet connection remains available for payments, cloud systems and operational traffic.
  • The app can remain responsive during temporary reductions in external speed, subject to how it is built.

This does not mean the internet becomes irrelevant. Cloud logins, external APIs, remote reporting and content not stored locally still need backhaul. The application has to be designed deliberately so local and external functions are separated safely.

Where else the approach can help

The same pattern can suit event schedules, exhibitor directories, menus, maps, training material, internal dashboards and operational forms. It is particularly useful where many on-site users repeatedly request the same content.

This is not a captive portal trick.

The aim is not to trap users on a login page. It is to place suitable event content close to the users, while keeping normal internet access and critical services available according to the network design.

Plan the application and network together

A local service still needs reliable Wi-Fi coverage, addressing, security, power and a method for content updates. The application team and event-network team should agree what runs locally, what remains cloud-based and what happens if either layer has a problem.

Have an event app or on-site system?

We can review whether it really needs to depend on the internet.

Send the event location, expected users and a description of the application.

Call Send details