About
One record of what happened
One incident record that survives the night and stands up afterwards.
What we are trying to fix
One incident ends up in a radio call, a paper log, a photo on somebody's phone and a group chat. All four are real, and none of them agree.
While somebody reconciles them by hand, nobody can see what is open, who is on it, and what is about to breach.
What we built instead
Someone scans a code that already knows which gate they are standing at, and the report reaches the queue and the map at the same moment.
A controller assigns it, the contractor takes it on their phone, and every step lands in the same append-only history.
At the end of the night it exports as a branded PDF, written as the night happened rather than reconstructed afterwards.
How we decide
The four rules we do not trade away
Isolation before features
Derived on the server and enforced in the database, never left to whoever writes the next query.
History is written once
No edit path, no delete path. Personal data is anonymised in place.
The reporter comes first
Nobody installs an app to report a broken step.
Live, or it is not operations
A control room that has to press refresh is reading the past.
Where we are
Built in the UK, for UK venues
EvoPoint is a small team in London. We are not trying to be a global incident platform that happens to be available here. The product is shaped around how UK venues, festivals, stadiums and managed facilities actually run, from the vocabulary in the interface to the region the infrastructure defaults to.
We would rather ship the thing a duty manager needs on a Friday than the thing that demos well. If you run a site and something in here is wrong for how you work, tell us.
- Site types
- Venue, festival, stadium, facility
- Dates and times
- DD/MM/YYYY and the 24-hour clock
- Spelling
- British throughout the product
- Billing currencies
- GBP, USD and EUR
- Hosting region
- AWS London, eu-west-2
- Database
- Supabase managed PostgreSQL