Can you work with our existing sensors?

Usually. Working with installed hardware is the normal case, and it constrains what is achievable — better established at the start than after a procurement decision.

What about devices with no mains power?

Power budget drives the design: reporting interval, radio choice and sleep behaviour. A device reporting every minute and one reporting hourly are different products.

How much data will this generate?

More than expected, and most of it is not worth keeping at full resolution. Downsampling and retention policy belong in the design rather than in a later cost review.

Do we need edge processing?

Where bandwidth is expensive or latency matters, yes. Otherwise sending raw data and processing centrally is simpler to operate and easier to change.

You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.

We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.

SERVICE

IoT development

Devices, ingestion and the software that makes the data worth collecting.

What this actually is

In short: An IoT system is three problems stacked: getting a device to report reliably from somewhere with poor power and worse connectivity, ingesting that at volume without drowning, and turning the readings into something a person or a process acts on.

The third is where most projects fail, and it is the one nobody scopes. A dashboard of live sensor values is not a product — it is a cost centre with a graph. The value is in the alert that arrives before a failure, or the reading that closes a work order automatically.

What we do

Device and firmware
Embedded software with power budgets, over-the-air update paths and a recovery mode, because a device you cannot update is a device you will replace.
Connectivity
MQTT, LoRaWAN, cellular or wired, chosen for the site rather than the datasheet — range, power and cost trade against each other differently in a basement than in a field.
Ingestion
Time-series pipelines sized for the real message rate, with buffering for the periods a device is offline and reporting a backlog.
Analytics and alerting
Thresholds, anomaly detection and the alerting that makes any of it useful, tied to an action rather than a dashboard.
Fleet management
Provisioning, health, firmware rollout and decommissioning. Manageable at ten devices by hand, and never at ten thousand.

The stack

MQTT
LoRaWAN
AWS IoT Core / Azure IoT Hub
TimescaleDB and InfluxDB
Python
C and embedded C++
Grafana
Kubernetes

What it connects to

Integration surface is the honest driver of effort — ten systems is not ten times one system.

SCADA and industrial control systems
CMMS and maintenance platforms
ERP for work-order creation
Cellular and LPWAN network providers
Cloud IoT platforms
Alerting and on-call tooling

How a project runs

Feasibility

2–3 weeks

Connectivity and power tested on the actual site, not on a desk.

Prototype

4–8 weeks

A small fleet reporting into a working pipeline.

Pilot

6–12 weeks

Real deployment with alerting tied to a defined response.

Scale

ongoing

Fleet management, OTA updates and the ingestion headroom volume needs.

Where teams use it

Manufacturing

Equipment monitoring where a vibration signature precedes a failure by days.

Logistics

Cold-chain and location tracking, where a breach has to be known immediately rather than at delivery.

Facilities

Occupancy, energy and environmental monitoring across a property portfolio.

Agriculture

Soil and weather sensing in places with no mains power and marginal signal.

Utilities

Metering and network monitoring at a scale where polling every device is not viable.

When this is the wrong answer

If nobody has decided what happens when a threshold is crossed, the system produces alerts nobody acts on and gets muted within a month.

Connectivity is the constraint that decides everything, and it has to be tested on the actual site. A device that works on a desk and not in a basement has taught you nothing.

Hardware has a lead time and a failure rate that software does not. Plan for units that arrive late, dead, or with a different revision of a component.

A fleet you cannot update remotely is a fleet you will visit. OTA is not a later feature — it is what makes the deployment survivable.

Frequently asked questions

Can you work with our existing sensors?
Usually. Working with installed hardware is the normal case, and it constrains what is achievable — better established at the start than after a procurement decision.
What about devices with no mains power?
Power budget drives the design: reporting interval, radio choice and sleep behaviour. A device reporting every minute and one reporting hourly are different products.
How much data will this generate?
More than expected, and most of it is not worth keeping at full resolution. Downsampling and retention policy belong in the design rather than in a later cost review.
Do we need edge processing?
Where bandwidth is expensive or latency matters, yes. Otherwise sending raw data and processing centrally is simpler to operate and easier to change.
Who owns the code?
You do, from the first commit — work happens in your repository under your licence, and the contract assigns IP outright. We keep no rights and build no dependency that makes leaving expensive.
What does it cost?
We do not publish a number, because the honest one depends on scope, integrations and the accuracy bar. Tell us the budget you are working with and we will say what it buys — or say plainly if it does not buy enough.