Case study · Connected products
The software that turned a device estate into an operable system.
Appnox delivered the full software layer around Tracer Technologies’ connected hardware — device provisioning and identity, telemetry ingestion, the mobile app used in the field, the web console the operations team runs, and the AI enablement that turns readings into a list of things worth doing.
The client problem
Devices in the field, and no system around them.
The hardware worked. What was missing was everything that makes a fleet operable at scale — a way to commission a unit without an engineer improvising, a place where its data becomes legible, and a mechanism for noticing a problem before a customer reports it.
Commissioning depended on manual steps that varied by whoever performed them.
Telemetry accumulated faster than anyone could turn it into an answer.
Faults were reported by customers rather than detected by the platform.
There was no single registry of what was deployed, where, running what version.
Each new device variant threatened another bespoke integration.
The data that would justify the product commercially was being collected and discarded.
What we built
One platform, one identity model, one place a human looks.
The foundation is a device platform that owns identity and connectivity: secure provisioning, a single registry of what exists and what it is running, and a command path that works the same way for every device class.
Around it sits the software people actually touch. A mobile application for the engineer physically at the device — pair, configure, verify, sign off, working offline because field sites rarely cooperate — and a web console where the operations team sees fleet health, exceptions and history without needing an analyst beside them.
The AI enablement came last and deliberately so. Once there was a clean, retained telemetry history, anomaly detection and condition monitoring could be built against something real: units drifting from their own normal, flagged as work worth scheduling rather than as an alarm nobody trusts.
- Provisioning and registrySecure onboarding and a single authoritative record of every deployed unit, its location and its version.
- Telemetry ingestionA pipeline designed for the fleet’s eventual volume, with normalisation and retention decided up front.
- Offline-first field appCommissioning, diagnostics and sign-off in the engineer’s hand, working with no connectivity at all.
- Operations consoleFleet health, exception queues and device history in a view an operations team uses daily.
- Anomaly detectionCondition monitoring against each unit’s own baseline, surfacing drift as scheduled work rather than noise.
- Business integrationDetected faults becoming dispatched jobs in the systems that already run service and billing.
Operational effect
What changes when this work lands.
Ranges below describe what engagements of this shape typically move. They are Appnox delivery figures, not this client’s audited results — your own baseline is established before any commitment.
30–45%
less time to triage a reported device fault
Typical range20–35%
fewer site visits for issues resolvable remotely
Typical range25–40%
faster commissioning of a new device on site
Typical range35–45%
less manual effort producing operational reports
Typical rangeIndicative ranges observed across comparable Appnox engagements. Not audited client results. Outcomes vary with scope, data quality and starting point.
How it was delivered
Prove one device class, then scale the pattern.
Connected-product programmes fail by designing for the pilot fleet rather than the production one.
01
Map the fleet as it will be
Device classes, connectivity conditions, expected volume and every human who touches a unit. Designing for the current ten units is the most expensive mistake available in this category.
02
Build the spine
Identity, provisioning and ingestion first. They are unglamorous and they determine whether everything above them is possible.
03
Put the app in real hands
Field conditions — signal, lighting, gloves, time pressure — change the design more than any workshop session. The app went to real engineers early.
04
Collect before predicting
Instrument and validate the data for long enough to have a defensible baseline, rather than shipping a model trained on a fortnight of readings.
05
Scale and hand over
Extend to the remaining device classes, and document the runbook for the day something goes wrong across the fleet at once.
Before we talk
Questions this usually raises.
No. We work from the device’s network interface inwards — provisioning, connectivity, data, applications, integrations and the AI layer. The hardware is the client’s, and we are explicit about that boundary in every connected-product engagement.
Against retained history rather than against a demo. Anomaly detection was built once there was enough clean telemetry to establish what normal looked like per unit, and it was evaluated on whether the flags it raised corresponded to work that genuinely needed doing.
That is the common case and it is workable. The platform, ingestion and operational view go in around the fleet as it exists, and the device-side software improves as units are updated or replaced.
Keep exploring
Related work
Start with a conversation
Bring us the workflow, not the technology.
If something here describes your operation, twenty minutes with a solutions architect is usually enough to establish what is worth doing about it.
Free · 20 minutes with a solutions architect · No obligation to commission an audit · sales@appnox.ai