IoT software, for hardware you cannot walk up to.
The distance between a device and the office.
Once hardware leaves the workshop, every question about it becomes a software question: is it online, what has it reported, why did that one stop, and how does it get updated without a van. We build that layer. Device identity and provisioning, the pipeline that carries telemetry back, the diagnostics that answer a fault from the office, and the update rollout that reaches a fleet safely. The code on the board itself is firmware, and that is a separate page.
The parts of a connected device system
Almost every fleet needs these five things eventually, and the order they become urgent is usually the order they are listed in.
Provisioning, identity, and onboarding
Every device needs a credential it can prove, given to it once and revocable later. Done properly, a unit is unboxed, powered on, and appears in the fleet without an engineer typing anything. Done badly, it is a shared key that can never be rotated.
- Per-device certificates and key rotation
- Zero-touch onboarding from first power-on
- Device registry with ownership and site
- Decommissioning and credential revocation
Telemetry, ingestion, and storage
Devices report constantly, unreliably, and out of order, so the pipeline has to tolerate all three. Messages arrive over MQTT or HTTPS, are buffered on the device when the link is down, and land in storage that answers both a live question and a year-old one.
- MQTT and HTTPS ingestion at fleet scale
- Store and forward through connection loss
- Time-series storage and retention rules
- Backfill handled without corrupting history
Device state, commands, and control
A device is somewhere between what the office asked for and what it has actually applied. We hold both, so a command issued while a unit was offline is applied when it returns, and the dashboard never shows a setting that did not take.
- Desired and reported state per device
- Commands queued through offline periods
- Configuration pushed per device or cohort
- Acknowledgement and failure reporting
Monitoring, alerts, and remote diagnostics
The value of a connected fleet is the visit you did not make. Faults, silence, and drifting readings raise alerts on rules you set, and a unit can be interrogated in place so the engineer arrives knowing what is wrong and carrying the right part.
- Fault, threshold, and silence alerting
- Remote log retrieval and live diagnostics
- Connectivity and signal health per site
- Fleet health dashboards and reporting
Over-the-air update rollout
The device knows how to install an update; that is firmware. This is the part that decides who gets it. A build goes to a handful of units, is watched, then widens, and stops on its own if failures climb, because a bad update pushed to a whole fleet at once is the most expensive mistake in connected hardware.
- Staged rollout by cohort and site
- Automatic halt on failure rate
- Rollback and version pinning
- Version inventory across the fleet
Integration with the systems that already run the business
Telemetry is only useful where decisions get made. Device data goes into the platform, the maintenance system, or the accounts, rather than sitting in a dashboard that somebody has to remember to open.
- APIs and webhooks out to your systems
- Ticket raised automatically from a fault
- Data exports and warehouse feeds
- Roles, permissions, and audit logging
A single control room for a distributed vending estate
A vending platform, and it is here because it is a connected fleet in the field: machines reporting in from many sites, into a live map showing what is online, what is left inside, what sold, and which unit needs a visit next. That is the shape of the problem whatever the hardware is.
Read the case study- 01Live machine map and telemetry
- 02Real-time sales and profit and loss
- 03Inventory and low stock alerts
How the work runs
Tell us what you need
A short written brief is enough to start: what you are building, the stack it has to live in, and the problem behind it. Someone technical reads it, not a sales rep.
passed when we reply with questions and a proposed shape
Scope and quote
We agree what the first release contains and what it costs before anything is built. Anything we cannot estimate honestly gets scoped on its own rather than padded into the total.
passed when the scope and the quote are agreed
Build in the open
Working software arrives in increments, in your repository, with our commits visible from the first week. Progress is something you can open and run, not a status report.
passed when a real user is doing a real job in it
Iterate, then hand over
What the first release teaches sets the priority for the next one. When you want it in house, documentation and a handover period are part of the engagement rather than an extra.
passed when your team can run it without us
How pricing works
Fixed price per milestone
You approve each milestone and its price before it starts, so the cost is known before the work is rather than after. Milestones are sized to be worth reviewing on their own.
Monthly rate for a dedicated team
A set team at a set monthly cost, with notice rather than a minimum term. Priorities move between sprints without renegotiating anything.
Scoping first, quote after
We work out what it should be with you before quoting it. There is no charge for that conversation and no obligation to go ahead.
Frequently asked questions
What you get, device to dashboard
Every build ships end to end, from first scope to live deployment and ongoing support.
