IoT solutions
Companies connect equipment for three reasons: to know where it is, to know it is working, or to sell it as a service. Each one needs a different build. We help you pick before you buy sensors.
Book a 30-minute scoping call See the platform we built
For the platform internals, protocols and firmware delivery, see our device platform page.
| How many units Now, and in three years | Sizing |
|---|---|
| How often they report Per minute or per day | Sizing |
| How long you keep it Months or a decade | Sizing |
| Who acts on an alarm And within how long | Sizing |
| Connectivity cost per unit Often the real constraint | Check early |
Pick the reason first
Most disappointing IoT projects tried to do all three at once, or never decided which one they were doing.
Tracking and utilisation
Condition monitoring
Connected product
Plain definitions
The first one sounds obvious and is not. The second one decides half the running cost.
Stripped of the marketing, it is equipment reporting its state to somewhere a person or a system can act on it. A reading, a route to send it, somewhere to keep it, and a rule that turns it into an action.
The connecting part is largely solved and cheap. What costs money is retention, the alarm path, and the fact that somebody has to own responding at three in the morning. Projects that skipped those questions are the ones sitting unused.
Cloud processing is simpler to build and change, and it is the right default. Edge processing means the device decides something locally before reporting, which cuts data volume and works when connectivity drops.
Push work to the edge when the connectivity bill is the constraint, when a decision has to happen faster than a round trip, or when the link is genuinely unreliable. Push it to the cloud when the logic will change often, because updating rules centrally is far easier than updating firmware across a fleet.
What we build
What people ask us for
These arrive most often. The third one is the project we have actually delivered end to end.
Our work
Case study, IoT platform
IoT Workz monitored device fleets through a third-party platform. Enterprise features sat behind tier upgrades, white labelling was unavailable, integrations were fragmented and the data was not theirs. We built a self-hosted replacement with white labelling, single sign-on, a visual rule engine, over-the-air firmware updates and tenant isolation, running on their own infrastructure.
Technology
We do not sell hardware. We work with the devices you choose or with your hardware partner, and we integrate through their protocols.
Who does the work
Fleet software is judged years after handover, when a rollout goes wrong or a threshold needs changing and nobody remembers who wrote it. We keep the team small so there is still somebody who does.
You interview whoever we put forward. A fair test is asking how they would size storage for ten thousand units reporting every minute for a decade.
How we work
The models differ in one thing: how much of the management you hand over. Everything else, including who owns the code, is the same in all five.
Changing model later is normal. Augmentation into a dedicated team is the common direction, and the people stay.
Engineers join your team and work inside your process, your board and your code review.
A team that works only on your product, with a lead on our side running delivery.
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
04
One price for a scope that is genuinely settled, with the overrun carried by us.
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
FAQs
Buy, if a product covers your case and you are comfortable with the data sitting in their cloud. Build when white labelling, self-hosting or per-tenant separation matter, or when the licence cost across your fleet has passed the cost of owning it. That was the IoT Workz position.
No. We work with the devices you choose or with your hardware partner, and we integrate through their protocols and SDKs.
Then the job is often extraction and migration rather than a new estate. We have moved a fleet off a SaaS platform onto self-hosted infrastructure.
Longer than feels necessary, because the day you want to train anything or defend a claim, you cannot go back and collect it. Time series storage makes that affordable.
Yes. Multi-tenant separation with white labelling is exactly what turns monitoring into a product you can sell.
You do, including the deployment, the data and the code.
One device reporting end to end, with an alarm reaching a person, is usually four weeks and proves more than a proposal does. A working fleet platform with provisioning, tenancy, dashboards and rules takes three to four months. Connectivity and retention costs run separately and forever, which is why we size them in week one. The build itself is billed by the engagement model above.
Wifi where the equipment sits inside a building you control and somebody will maintain the credentials. Cellular where units move or sit on customer sites, at a per-unit monthly cost that often turns out to be the real constraint. LoRaWAN where readings are small and infrequent and battery life is measured in years. The decision follows the reporting frequency and the power budget rather than the other way round.
Silence has to be an alarm in its own right, otherwise a dead sensor reads as a healthy machine. We set an expected reporting interval per device type and raise a missing-data alert when it lapses, which is a rule teams routinely forget until the first time it matters.
Tracking, condition monitoring and connected products look similar on a slide and diverge completely in the build. Thirty minutes is enough to tell which one you are doing.
