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
The public-sector editions run 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 — including the images you see in the app — lives here, so there's one consistent, backed-up source of truth.
- 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.
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 — the app's interface translates itself into multiple languages using Claude, so crews can use it in the language they're most comfortable with.
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.