When someone is deciding whether to turn out, the tool in their hand has to just work. A lot of our effort goes into the part nobody sees: the engineering that keeps iOnCall fast, available, and safe with people's data. This page explains how that fits together.
One platform, three apps
Built once, shared everywhere
We run three branded editions — iFire for fire & rescue services, iCrew for lifeboat and rescue crews, and iRescue for HM Coastguard teams. They're not three separate products: they're built from a single codebase and served by a single API, and they run natively on both iOS and Android.
That means every improvement, fix and security update lands in all three apps at once. And because each organisation's data is logically separated and scoped to them, different services share the same proven platform without ever sharing each other's information.
Built on AWS, in the UK
Designed to stay up
iOnCall runs on Amazon Web Services in its London region, so data stays in the UK. Rather than one big server that becomes a single point of failure, iOnCall runs as a load-balanced fleet: several identical servers behind a load balancer that shares traffic between them. If one server has a problem, the others carry on without a blip — and when we need more capacity, we add another server to the fleet. Each server runs as a managed Windows service, so it starts automatically with the machine and is brought back on its own after any restart — planned maintenance or an unexpected reboot — with no one needing to log in and start anything.
Fast, and consistent across the fleet
Behind the fleet sits the data layer, built around proven, managed services:
- The database is Amazon RDS — a managed, encrypted database with automated backups. Every connection to it is made over an encrypted, pooled link, and everything your station puts in — including profile and map photos — lives here, so there's one consistent, backed-up source of truth.
- The app's own artwork — status icons, flags and brand logos — is served from Amazon S3 in the same London region.
- A shared cache — Valkey, running on AWS ElastiCache — keeps frequently-needed information instantly to hand and is shared by every server in the fleet, so they all see the same up-to-date picture and the database isn't asked the same question over and over.
The cache is deliberately designed so that even if it were unavailable, the apps keep working — they simply read from the database instead. It makes things faster; it's never a single thing that can take the service down.
Live updates on every screen
The Station Dashboard and the crew board — the page a station shows on its crew-room TV — update the moment something changes, without reloading. Each one keeps a connection open to the server (server-sent events), and when someone at the station changes their status or responds to a callout, the server sends a short “this station changed” message down every open connection for that station. The screen then fetches the new picture.
Because a screen can be connected to any server in the fleet, the servers pass these messages to each other through Valkey's publish/subscribe channels, so a change made through one server reaches screens connected to all the others.
Talking to the outside world
A few specialised jobs are handled by best-in-class services rather than something we'd build ourselves:
- Push notifications — the mobilisation alerts and status updates that need to cut through — go out through Firebase Cloud Messaging, with the right payload for each platform so an alert behaves correctly on both iOS and Android.
- Email — verification codes and account messages — is sent through Postmark, a service built specifically for getting important email reliably into inboxes, with a second provider on standby as a fallback.
- Translation — text that comes from the server, such as status names and ranks, is translated into each crew member's language using Claude.
- Payments — station subscriptions are billed through Stripe. Card details are entered on Stripe's own checkout page and never reach our servers.
- Tides and wind — a crew board can show live tide heights and wind from the Humber weather stations run by Associated British Ports. Our servers fetch the readings in the background, at most once a minute, and every board reads the copy we already hold, so a slow feed never slows a board down.
The app in your pocket
On the phone, the same care goes into the everyday experience. iOnCall uses native maps on each platform — Apple Maps on iOS, Google Maps on Android — for smooth, familiar mapping with your own location built in. Images are cached on the device so the app stays quick even on a patchy signal, and sensitive information is held in the phone's secure, encrypted storage.
On the web, the Station Dashboard's en-route tracker and its hydrant and defibrillator map use Google Maps. The crew board's responders map, shown only on screens a station admin has paired, uses OpenStreetMap map tiles drawn with the open-source Leaflet library.