Response Technologies · 2022 — present
A panic button, an app, and the cloud between them
A BLE-enabled personal safety device where pressing a button has to raise an alarm — reliably, from a coin-cell device, through a phone that may be backgrounded, to a backend that has to notify someone within seconds. I own the firmware, both mobile apps and the serverless infrastructure behind them.
- Role
- Senior Software Engineer — firmware, iOS, Android, cloud infrastructure
- Stack
- Shipped on both public app stores
- Firmware, apps and infrastructure under one owner, so the protocol has one author
- REST API that integrates with a wide range of EMS providers
Why this one is hard
Most connected products can tolerate a dropped message. A panic button cannot. The whole value of the device is the guarantee that pressing it does something, which means the interesting engineering is not the happy path — it is every way the path can fail.
The device is a Nordic SoC running Zephyr RTOS on a constrained power budget. It talks to a phone over Bluetooth Low Energy. The phone talks to the cloud over MQTT. Any one of those hops can be down at the moment it matters most.
What I built
Firmware. Zephyr RTOS on a resource-constrained target, with the power budget and the alarm latency in direct tension — the radio is the expensive part, and the answer is mostly about when not to use it.
Both apps. Centurion Anywhere in Swift and Kotlin, natively on each platform, with MQTT integration and the BLE connection lifecycle handled properly: pairing, bonding, reconnection, and the background execution rules each platform imposes. Both are on the public app stores. I also took over the legacy Centurion Anywhere Classic app and spent real time on its stability.
The cloud. Serverless on AWS, defined in Terraform, with low latency as the design constraint rather than an afterthought. Plus a REST API built for integration with a wide range of EMS providers — which in practice means designing for other people’s constraints rather than your own.
A cryptographic signer, because a device that can summon emergency services is a device worth impersonating.
The part that generalises
The reason this works is that one person owns the protocol at every hop. When the firmware engineer, the app engineer and the backend engineer are three different contracts, the wire format between them becomes a negotiation, and version skew becomes somebody else’s problem. Here it is nobody else’s problem.
That is the whole argument for working across the stack rather than a layer of it.