Offline-first
Ten thousand phones, one cell tower.
This is where most festival apps fail. Service drops at the gate and the schedule turns into a spinner on the one night it mattered. Every screen here loads from the phone first, syncs when it can, and never blanks itself on a failed fetch.
Why it works
Cache first, everywhere
Load the cache, show it, sync in the background, refresh. No critical screen waits on the network. The rule is in the architecture, not the settings.
A failed sync leaves the last good copy
Content is fetched first and replaced second. A timeout, a 403 from an embargo or a broken response throws and leaves the cache intact. Nothing erases the lineup off ten thousand phones.
Enforced by the build
A test fails the build on any image that is not disk-cached. Reminders are scheduled on the device, not a server. Writes queue in an outbox. The offline rate is measured in analytics so you know how often it mattered.
What you can expect
What ships,
screen by screen.
Everything readable offline
Lineup, set times, My Night, the map and its pins, vendors, FAQ, quick actions, news, sponsor creative, afterparty posters.
Everything writeable offline
Saving a set, sending a crew request, filing a Lost and Found report. Each goes into an outbox and drains when the phone finds a tower.
Reminders that do not need a server
A saved set schedules a local notification on the phone in the venue's timezone. It fires at the stage with zero bars.
Cached three deep on the server too
Redis, an nginx micro-cache and a device ETag. Load-tested at over 8,000 requests a second on the box that runs Eternal NYE, so doors-open does not take down the API either.
Included
On every plan, from Core up.
Works with
Ready to put your festival
in every pocket?
- No development team on your side
- Content in hand to the store in about six weeks
- You own the app, the data and the sponsor revenue