Presso Events
What is a Progressive Event App?
We published the first version of this post in April 2025, and it was a bit pleased with itself. It treated “PEA” as a joke we were in on, and it made two claims about our own product that we could not stand behind on inspection. This is the rewrite. The original argument was right; some of the evidence for it was not.
PEA stands for Progressive Event App. That is the only thing it stands for.
The problem is the download, not the app
Nobody wants to install software for a two-day conference. Not for a one-off networking evening, not for a week-long summit, and especially not on a work phone that blocks installs outright.
The install is not one barrier. It is four, and each one loses a share of whoever is left: find the right app among the near-identical ones, download it, open it, then make an account. At an event you get one attempt at this, usually while someone is walking to a venue.
So the question worth asking is not “how do we get more people to install our app?” It is “why is there an install?”
What a Progressive Event App is
An event companion that runs in the browser. The attendee opens a link or scans a code and is in their event: their ticket, the agenda, the speakers, the venue.
Technically it is a Progressive Web App, and it is worth being straightforward about that rather than implying we invented a new technology. We did not. A PWA is a well-established web platform pattern, it has worked on iOS since 2018, and the machinery is the same.
What the term adds is a set of constraints that come from events rather than from the browser. A general PWA usually wants an account, wants to persist on your home screen forever, and would love to prompt you to install it. For an event companion used across two days, all three of those are wrong. The attendee already identified themselves when they bought a ticket, and the software has no business outliving the event.
That is the useful part of the name: not the technology, but which habits to drop.
What it actually does
- Nothing to install. A link or a QR code. It opens in the browser they already have open.
- No account. Their confirmation email contains their ticket. There is nothing to register for and no password to forget at the door.
- Add to home screen if they want to. Optional, never required, and nothing is withheld from anyone who ignores it.
- Changes are live. Move a session and every open app reflects it on the next load. There is no release to submit and no update for anyone to install.
- Push notifications, with a caveat worth stating: on iOS, web push requires the attendee to have added the app to their home screen first. In a browser tab it will not fire. That is an Apple platform rule, not something a vendor can engineer around, and anyone telling you otherwise is selling.
What about signal at the venue?
This is where the original post overreached, so here is the straight answer.
Our attendee app installs a service worker, which keeps the app shell available if the network drops. It is deliberately not an offline data cache. Ticket and agenda data is personal and changes during an event, and showing someone stale personal information without saying so is worse than showing them nothing.
So we do not claim your attendees can browse the full programme in a dead zone.
What we do claim is checkable: every ticket carries a six-character check-in code as well as a QR code, and it is built to be read aloud. Check-in accepts it with hyphens, spaces or the wrong case, and it reads I and L as 1, and O as 0, because that is how people actually read characters to each other across a busy desk.
The door does not depend on the attendee’s phone working. Flat battery, saturated wifi, cracked screen: they read you six characters and they are in. That is a smaller promise than “it works offline”, and it is one we keep.
Caching the agenda and the ticket properly is on our list. When it ships, we will say so here.
About the numbers we used to quote
The first version of this post said native event app adoption was “63% on a good day” and that ours was “near-100%”.
We have since gone looking for the source of the 63%, because it appears everywhere in this industry. It traces to an event technology vendor’s blog post with no underlying report, no sample size, no date and no definition of what “adoption” counts. We were repeating it because everyone repeats it.
Our own “near-100%” was no better. It came from our events, measured by us, with no published method.
There is a structural problem underneath this that applies to every vendor including us: an event app company only sees events that bought an event app. The denominator is missing. You cannot derive a population adoption rate from that data however carefully you compute it.
So we have taken both numbers out. The argument for removing the download does not need them. It rests on something you can check yourself: count the steps between an attendee’s email and their ticket, on your last event, and on this one.
The short version
Friction kills attendance of the thing you built. Every attendee should get the whole experience with no exceptions and no prerequisites. If it can be a web page, it probably should be.
That is what a Progressive Event App is. And it is a category, not a product name, so if someone else builds one properly we would rather they used the term correctly than avoided it.
Updated September 2026: rewrote for accuracy. Removed two unsourced adoption statistics and a claim about offline access that our own code does not support, and dropped the “Presso Event App” wordplay. PEA is a Progressive Event App.