By industry
IoT software, device integration and AI on connected device data
The devices usually work. What does not work is everything after the device: getting the telemetry somewhere useful, keeping a fleet in a known state, noticing a fault before a customer does, and turning a stream of readings into something a person can act on. We have written both sides of that boundary — custom firmware and the software it talks to.
Two weeks to a written build plan · no obligation to build with us
- We have shipped both sides
- Firmware + appWe have shipped both sides
- Events survive a lost connection
- Offline-firstEvents survive a lost connection
- We do not write to control systems
- Read, not driveWe do not write to control systems
- To a written build plan, via the audit
- 2 weeksTo a written build plan, via the audit
Where the time goes
If two of these are true, there is something here
Written the way the people doing the work describe it, not the way a process document does.
The data lands somewhere and stops
Telemetry arrives in a broker, a bucket or a vendor dashboard. Turning it into an alert, a report or a decision is a project nobody has started.
Faults are reported by customers
A device has been failing for a week in a way the readings would have shown. The first anyone hears is a complaint.
The fleet is in an unknown state
Three firmware versions in the field, no reliable inventory of which device is on which, and no safe way to move them forward.
Every device generation speaks differently
Field names, units and sampling rates changed between hardware revisions, so every query starts with a translation nobody has written down.
What we connect to
The systems you are already running
IoT work is mostly integration at two edges — the device protocol at one end and the business system at the other. We work at both.
- Device and transport
- MQTT
- LoRaWAN
- Modbus
- OPC-UA
- BLE
- Cellular / NB-IoT
- Serial protocols
- Platforms
- AWS IoT Core
- Azure IoT Hub
- Self-hosted brokers
- Time-series databases
- Grafana
- Business systems
- ERP
- CMMS / maintenance tools
- Ticketing
- Billing systems
- Mobile field apps
What we build here
Five things worth building for iot & connected devices
Each one names the systems it touches, because an integration that is not named is an integration nobody has thought about yet.
- 01
Telemetry pipeline and canonical model
One schema across device generations, with per-revision translation written down rather than remembered, units normalised, and raw payloads kept so a decoding mistake can be reprocessed instead of lost.
- Touches
- Broker / gateway · time-series store · raw archive
- What changes
- Queries stop starting with "which hardware version is this?"
- 02
Anomaly detection against a device’s own baseline
Each device compared with its own history and with its cohort, rather than with a global threshold. A compressor that has always run warm should not alert daily, and one that has started running warm should.
- Touches
- Time-series data · device metadata · alerting
- What changes
- Alerts that engineers act on rather than mute.
- 03
Fleet and firmware state
A reliable inventory of what is deployed, on what version, with what configuration and last contact — plus staged rollout with health checks and a rollback path that does not depend on a site visit.
- Touches
- Device registry · update channel · telemetry
- What changes
- A fleet you can move forward without a truck roll or a held breath.
- 04
Field engineer support
A mobile view that shows a device’s recent readings, error history and previous interventions before the engineer opens the panel, and captures what was done in a form that feeds the next diagnosis.
- Touches
- Mobile app · telemetry · maintenance records
- What changes
- Fewer second visits for something the data already knew.
- 05
Device data into business systems
Usage-based billing lines, warranty and service triggers, consumable reordering and SLA reporting driven from actual device data rather than from an assumed duty cycle.
- Touches
- Telemetry · ERP / billing · ticketing
- What changes
- The commercial side finally runs on what the devices did.
How it is put together
How a reading becomes an action
The design assumption throughout is that connectivity is unreliable and that hardware revisions will keep happening. Both are true everywhere, and systems that assume otherwise fail in the field rather than in testing.
- 01
Buffer at the edge
Devices and gateways record locally with their own event ids and replay when they reconnect. Nothing depends on the network being up at the moment something happened.
- 02
Ingest and archive raw
Payloads are stored exactly as received before decoding. When a decoder turns out to be wrong for one revision, the fix is a reprocess rather than a gap in the history.
- 03
Normalise
Per-revision translation into one canonical model, with units and sampling differences handled explicitly. This is the layer that stops every downstream query from needing tribal knowledge.
- 04
Detect
Baselines per device and per cohort, with thresholds you set. Detection is tuned for alert fatigue first — an alerting system engineers ignore is worse than none, because it is trusted on paper.
- 05
Act
Tickets raised, engineers paged, billing lines created, consumables reordered — through scoped writes into your existing systems, with the readings that triggered them attached.
Your data
What we will and will not do with it
Stated plainly, and without claiming a certification we do not hold. If a requirement here is harder than what is written, say so on the call and we will tell you whether it is buildable.
We do not write to control systems
We read from PLCs, controllers and industrial equipment. We do not write setpoints or issue commands to machinery. That boundary is not negotiable, whatever the convenience argument.
Firmware updates roll out staged, with a rollback
No fleet-wide push without a canary group, health checks between stages and a tested rollback. A bad update on devices you cannot physically reach is the most expensive failure in this sector.
Device data can stay entirely in your environment
Telemetry frequently identifies a customer, a site or a process. The whole pipeline, including model inference, can run in your cloud account or on your own hardware, with nothing leaving it.
Proof
We write the firmware as well as the software
For Bguest we built the operations system and the custom firmware for the devices it talks to, so floor and kitchen state stay in one picture in real time. ReCyrcle added the other half of this page: IoT sync to collection hardware, with events surviving unreliable connectivity in the field. Both are production systems, not prototypes.
- Written by us, not bought in
- FirmwareWritten by us, not bought in
- Floor-to-kitchen state
- Real timeFloor-to-kitchen state
Technology
What this gets built with
We pick the boring option unless there is a reason not to — the framework is the part most likely to be abandoned before your system is.
- Firmware and edge
- Embedded C
- FreeRTOS-class targets
- Serial protocols
- Local buffering
- OTA update
- Transport
- MQTT
- LoRaWAN
- Modbus
- OPC-UA
- AWS IoT Core
- Azure IoT Hub
- Data
- TimescaleDB
- PostgreSQL
- Raw payload archive
- Grafana
- Anomaly baselines
- Applications
- Flutter field apps
- Next.js dashboards
- FastAPI
- Ticketing integrations
How the engagement runs
Five phases, each with something you can hold
Every phase ends in a named deliverable. You can stop after any of them and keep what has been built.
- 01Week 1–2
Sit with the work
We watch the process as it is actually done, not as the process document says. The output is a map of every step, which system it touches and how long it takes.
DeliverableProcess map and a shortlist of what is worth automating - 02Week 2–3
Design the access layer
Which systems get read, which get written to, what scope each credential carries, and which decisions stop for a person. Agreed in writing before anything is built.
DeliverableArchitecture and permission model - 03Week 3–8
Build against your real data
Built in your sandbox against real records, not a demo dataset. The write path goes through a review queue from the first day, so nothing lands in a live system unseen.
DeliverableRunning system in staging, with the review queue - 04Week 8–10
Run it beside the humans
It runs in parallel with the people doing the job. We compare the two outputs, fix what differs, and only then start letting the routine path through unattended.
DeliverableAgreement rate report and a go-live threshold - 05Ongoing
Hand over and watch
Source code in your repository, deployment in your accounts, cost and failure dashboards you can read without us. Support if you want it, not because you are locked in.
DeliverableRepository, runbook and monitoring
Why Devs Core
Three reasons that are checkable
We run two of our own products
Cadenza and Budge are ours. What an agent costs per run, where it fails and which decisions need a person came from operating them, not from a vendor deck.
The write path is reviewed by default
Anything that changes a record in a system of record goes through a queue a person can see. You choose what graduates to unattended, and when.
You own the code
Source in your repository, infrastructure in your accounts, model keys in your name. There is no runtime of ours you have to keep paying for.
Questions
IoT & Connected Devices — the questions we get asked
Do you design hardware?
No. We write firmware for devices and everything above it. Board design, enclosure and certification are someone else’s discipline, and we will say so rather than take the work and learn on your budget.
Can AI predict failures in our devices?
Sometimes, and it needs history including actual failures — a year of healthy telemetry teaches a model nothing about breaking. We would usually start with anomaly detection against each device’s baseline, which is useful immediately, and revisit prediction once there is labelled failure data worth training on.
Our devices are already on a vendor cloud platform. Is that a problem?
Not usually. Most platforms will export or forward telemetry, and we build the layer that makes it useful. If a platform is genuinely closed, the honest options are to add an independent path at the gateway or to accept the limits, and we will tell you which.
How do you handle sites with almost no connectivity?
By assuming that is the normal case: buffer locally, replay on reconnect, deduplicate on device event ids, and never let a lost connection destroy an event. It is the design ReCyrcle needed in the field.
Can you take over an IoT project someone else started?
Yes — that is AI Build Rescue with hardware attached. The first step is a read-only assessment of what is deployed, what it emits and what state the fleet is actually in, because on device projects that is usually less known than anyone expects.
Who owns the firmware and the code?
You do. Source in your repository, build pipeline in your accounts, signing keys in your control. Firmware you cannot rebuild without your vendor is a much worse trap than software you cannot rebuild.
Related
What iot & connected devices buys most often
- Read more
Custom Software Development
The operational system underneath — the one the packaged software did not cover. React and Django, built to be handed over.
From $14,000 - Read more
AI Integration Services
The access layer between the software you already run and any AI model — so an agent can reach your ERP, CRM or helpdesk without being handed the keys.
From $8,000 - Read more
Mobile App Development
iOS and Android from one Flutter codebase, or native where the hardware demands it.
From $9,000 - Read more
AI Build Rescue
For a pilot that impressed everyone in the demo and then stalled before production. We take it over, find what it is missing, and get it live or tell you to stop.
From $3,500
- By industry
Manufacturing & Textiles
The accounts and the stock do not match, and nobody knows until month end.
- By industry
Sustainability & Recycling
Collection data sits in hardware nobody can get a report out of.
- By industry
Hospitality & Restaurants
The floor, the kitchen and the books each have a different version of tonight.
Tell us which process is costing you.
Thirty minutes, no preparation, no deck. You describe what keeps going wrong and we tell you whether AI is the answer — including when it is not.
Prefer email? contact@devs-core.com