Most app companies keep the engineering behind closed doors. We'd rather show you. We're genuinely proud of how iOnCall is built, and we think the people who trust it with something as important as turning out to a shout — and anyone simply curious about what's under the hood — deserve a straight answer about what's actually running when you open the app. So here's the tour, warts-and-all honest and without the marketing gloss.
A quick disclaimer for the curious: this is more engineering than a crew-availability app strictly needs. We think that's exactly the point.
One codebase, three apps
We ship three branded editions — iFire for fire & rescue services, iCrew for lifeboat and rescue crews, and iRescue for HM Coastguard teams. The temptation, and the route most teams take, is to build and maintain three separate products. We didn't. iOnCall is one codebase served by one API, and the brand is worked out fresh on every single request from the address the app is talking to.
The payoff is enormous. Every improvement, every fix and every security update lands in all three apps at once — there's no “we'll port it to the other apps next sprint”. And each organisation's data is logically separated and scoped to them, so different services share one proven platform without ever sharing each other's information.
A fleet, not a server
iOnCall runs on Amazon Web Services in its London region, so data stays in the UK. But it doesn't run on a server — it runs on a load-balanced fleet of identical servers sitting behind a load balancer that shares the work between them. There is no single machine whose failure takes the service down. If one drops out, the others simply carry the load; when we need more headroom, we add another server to the fleet rather than nursing one ever-bigger box.
The server itself is a compiled, native application — not a stack of interpreted layers — and each instance runs as a managed Windows service. That matters more than it sounds: a service starts itself with the machine and is brought back automatically if it ever stops, so when a server reboots — planned maintenance or an unexpected blip — iOnCall comes straight back on its own, with nobody needing to log in and start anything. Lean, quick, and self-recovering.
Built to keep running when things go wrong
Anyone can draw a fleet on a slide. The interesting part is what happens when something breaks — and that's where most of our thinking has gone.
- The scheduled work elects a leader. Plenty of jobs happen quietly in the background — resetting statuses, sending the day's emails, tidying up. Run those on every server in the fleet and you'd send everything three times over. So the fleet elects a single leader to own that work. If the leader disappears, another server takes over automatically on its next beat. Nobody gets three copies of anything.
- The cache is allowed to fail. We keep a fast shared cache in front of the database, but it's designed to fail open: if it falls over entirely, the apps don't — they quietly fall back to reading from the database. The cache makes things faster; it is never a thing that can take the service down.
- The heavy lifting happens off the critical path. When a big shout goes out, dozens of people change their status in the same moment, and every one of those changes means notifying the rest of the crew. We move that fan-out off the request and onto a queue that a worker drains in the background. The upshot: the person tapping “responding” gets an instant reply, even while the alerts are flying out to everyone else.
The data layer
Behind the fleet, the data layer is built from proven, managed services rather than anything we'd hand-build and have to babysit:
- A managed, encrypted database (Amazon RDS) with automated backups, reached only over encrypted, pooled connections.
- Durable object storage (Amazon S3) for images, so photos and avatars don't live on any one server.
- A shared in-memory cache (Valkey, on AWS ElastiCache) that every server in the fleet sees, so they all work from the same up-to-date picture and the database isn't asked the same question again and again.
We use the best tools — and talk to them directly
Where a specialist does a job better than we could, we use them — but we integrate cleanly and on our own terms, rather than dragging in heavyweight third-party SDKs:
- Email goes through Postmark, which exists to get important mail reliably into inboxes — with a second provider kept on standby so a verification code is never stuck behind one supplier having a bad day.
- Push notifications — the alerts that have to cut through silent mode — go via Firebase, talking to it over its secure modern interface with credentials we mint and sign ourselves, with the right payload for each platform so an alert behaves correctly on both iOS and Android.
- Translation is where it gets fun: the app's interface translates itself into many languages using Claude, so a crew member can run iOnCall in the language they're most comfortable with — no army of human translators, no half-finished language packs.
On the phone, the same standard applies: native maps on each platform (Apple Maps on iOS, Google Maps on Android), images cached on the device so the app stays quick on a patchy signal, and sensitive data held in the phone's secure, encrypted storage.
Tested to the hilt
Here's the part we're quietly proudest of. None of the above is worth much if a change quietly breaks something — so every change ships with tests. A new feature, a bug fix, a behind-the-scenes refactor: all of it lands alongside automated tests that prove it works and keep it working. Between the server and the app there are several thousand of them, and they all run green before anything reaches your phone. It's slower to build that way. It is a great deal safer to rely on — and when your tool's job is to help get people to an emergency, “safer to rely on” is the whole game.
Good engineering isn't the longest list of technologies. It's choosing proven building blocks, putting them together with care, and making sure the whole thing keeps working when it matters. That's the bar we hold ourselves to.
Why we're showing you all this
Because we can, and because we're proud of it. We're a small team that builds like a serious one, and we'd rather be open about how iOnCall works than hide behind a glossy feature list. If you're curious about anything here — or you're weighing up a tool like this for your service and want to talk specifics — we'd genuinely enjoy the conversation. You'll find us at hello@ifireapp.net.