Every device accounted for, wherever it is
Provisioning, updates, fleet health and remote diagnostics for connected devices, so you can run the fleet without driving to it.
In short
Building one connected device is a project. Running a fleet of them across stores, estates or farms is a different job. You need to know which devices are online, what firmware they're running, which ones need attention and how to fix them from where you sit. We build the device management layer that makes that possible, and because we write the firmware too, the device and the platform are designed to work together from the start.
What we build
The tools to run a fleet
Device management covers a device's whole life, from the moment it's switched on to the day it's retired.
- 01
Provisioning
Getting each device registered, identified and assigned, in the factory or on site. Woolworths stations could be added simply by scanning the QR code on the device.
- 02
Fleet organisation
Every device allocated to an organisation and a location, so each customer, region or site sees exactly what it owns.
- 03
Over-the-air updates
Firmware updates sent remotely, to a few devices first and then the fleet, with every device's version tracked.
- 04
Fleet health
Online and offline status, last check-in and alerts for every device, so problems are spotted before a customer reports them.
- 05
Remote diagnostics
Each device's data, statistics and alerts on hand in the platform, so a fault can be understood, and where possible fixed, without a site visit.
- 06
Connectivity
Wi-Fi, 4G/LTE or a low-power network, chosen for where the device lives, what it sends and what the connection will cost to run.
End to end
Management designed in, not bolted on
Device management only works if the device was built to be managed. It needs an identity, a way to report its health and firmware that can take an update safely. Bolt a management platform onto a device that wasn't designed for it and you end up with blind spots.
We build both ends. For the Woolworths sanitiser stations, a device could be created from a template, by scanning the QR code on it or by manual entry, then allocated to its organisation and location. From there, the backend showed each device's data, statistics, alerts and notifications.
Where it makes sense, we build on established platforms such as AWS IoT and ThingsBoard rather than reinventing them, and add the parts your operation actually needs.
The Handee Method
Built to keep running
The Run phase of the Handee Method is where device management lives: after launch we run the fleet, and our engineers decide.
- 01
Watching the fleet
We watch fleet health and anomalies after launch, so unusual behaviour is flagged for an engineer before it becomes an outage.
- 02
Nothing lost, nothing doubled
Requests are idempotent, so a retry after a dropped connection never acts twice, and a transactional outbox makes sure no event is lost.
- 03
A full audit trail
Security events are written to append-only logs that can be added to but never changed, so every action on the fleet can be traced.
- 04
Secure by default
Passwords hashed with scrypt, sessions and tokens stored hashed, security headers on and signature-checked callbacks on the platform that controls your devices.
The Handee Method
From brief to fleet, in four steps.
Discover
We map the devices, the data they must produce, the systems they plug into and the conditions they must survive.
You get
A scoped build, a plan and a price.
Prototype
We build a working slice first: real firmware on real hardware, a live cloud and a first screen. You hold it in days.
You get
A working prototype on real hardware.
Build
We take it to production: device, cloud and apps, built in short reviewed loops, tested and documented as we go.
You get
Production firmware, cloud and apps.
Run
After launch we run the fleet: device health, anomalies, over-the-air updates and dashboards for your team.
You get
A live fleet, monitored and updated.
Related work
Fleets we've built for
Where devices out in the world meet the people who depend on them.
Your fleet
Tell us about your fleet
Tell us about your fleetA few lines is enough: what the devices are, roughly how many, where they live and how you manage them today. We'll tell you honestly what to build and what to buy.
- 01Talk directly to the engineers who will build it
- 02Honest advice on building versus using a platform such as AWS IoT
- 03A clear next step, whether or not we end up working together
What happens next
- 01We read your briefWe come back to you, usually with a few questions about your devices and how they connect.
- 02A first callWe talk through the fleet, how it's managed today and what goes wrong.
- 03A clear proposalScope, timeline and cost for a first phase, so you know exactly what you're committing to.
Questions
Device management questions
What buyers usually ask us before a device management project starts.
01Should we build device management or buy a platform?
Often both. Platforms such as AWS IoT and ThingsBoard already handle device identity, messaging and much of the plumbing well, and rebuilding that rarely makes sense. What they don't know is your business: which customer owns which device, what counts as a fault and who gets told. We usually build on a platform and add that layer, and we'll say so if an off-the-shelf tool alone is enough.
02Are devices provisioned in the factory or in the field?
Either, and we design for the one that fits your process. Devices can be given their identity during manufacture or registered on site. For the Woolworths stations, a device could be created by scanning the QR code on it, then allocated to its organisation and location. What matters is that every device ends up with its own identity and nobody has to type secrets in by hand.
03How do you roll out firmware updates without breaking the fleet?
In stages. An update goes to a small group of devices first, their health is checked, and only then does it go wider. Every device's firmware version is tracked, and the firmware is designed to fall back if an update fails rather than go dark. That way a bad release is a contained problem, not a fleet-wide one.
04Wi-Fi, 4G, LTE-M, NB-IoT or LoRaWAN: which should we use?
It depends on where the devices live, how much data they send, how they're powered and what the connection costs each month. Shared site Wi-Fi is often outside your control, while low-power networks suit small, infrequent readings on battery. The Woolworths stations, for example, each carried their own 4G/LTE modem. We compare the options against your devices in discovery, running costs included.
05What does connectivity cost to run?
Connectivity is an ongoing cost, usually charged per device, and it grows with how much each device sends and how often. We design messages to be compact and send only what's needed, which keeps data costs predictable. We'll help you estimate running costs before you commit, so they're part of the business case rather than a surprise.
06Can you diagnose problems without sending someone to site?
That's the point of remote diagnostics. Devices report their status, readings and errors, so an engineer can see what's wrong from the platform, and many issues can be fixed with a configuration change or an update. When someone does have to go, they go knowing what the problem is and what to take.
07What happens to the fleet over the years?
Devices outlive their first firmware. We plan for patches, new features, hardware revisions and eventually retiring devices, so the platform always shows which devices run which version and which need attention. After launch, the Run phase of the Handee Method has us running the fleet: device health, anomalies and over-the-air updates, with our engineers accountable for it.