Not us
Silicon and boards
- Schematic capture and PCB layout
- Bare-metal drivers for a new chip
- Safety certification of the hardware itself
- Mechanical design and enclosures
You need an electronics house for these. We work alongside them regularly.
Embedded and device software
The platform your devices report into
We work at the line between hardware and software: telemetry off device fleets, over-the-air firmware delivery, rule-driven alarms, and readings pulled from instruments over Bluetooth and vendor SDKs.
Book a 30-minute scoping call See the device work
We are honest about the boundary: read the first FAQ before you call.
| Telemetry in MQTT, CoAP and HTTP | Streaming |
|---|---|
| Firmware version Rollout paused at 40 percent | 2.4.1 |
| Critical alarms Since go-live | Zero |
| History retained Time series, queried in full | Years |
| Where it runs Customer's own infrastructure | Self-hosted |
Device work we have delivered
- IoT WorkzESP32 fleets over MQTT, zero critical alarms
- OTA firmwareDelivery and rollout control
- Hydrajaws LimitedInstrument readings over a vendor SDK
- Self-hostedCustomer owns the platform outright
Where the line is
What we do and do not do with hardware
Embedded covers a wide range. Being clear about our half saves everyone a wasted call.
Us
Everything the device talks to
- Ingesting telemetry from fleets over MQTT, CoAP or HTTP
- Storing readings as time series that stay queryable for years
- Rule engines that turn a value into an alarm and an action
- Over-the-air firmware delivery, staged and reversible
- Reading instruments from a phone over Bluetooth or a vendor SDK
- Provisioning, identity and multi-tenant separation for device estates
This is the IoT Workz platform, running ESP32 fleets in production.
Plain definitions
Two questions that sort out who you actually need
Embedded is a wide word. These two answers usually tell you whether to call us or an electronics house.
Firmware or embedded software?
Firmware is the code burned into the device that makes the hardware itself work. Drivers, bring-up, the bare-metal or RTOS layer that talks to the silicon. It is written against a specific board and it ships with the board.
Embedded software is the broader layer above that: the application on the device, the protocol it speaks, and the platform it reports into. We work in that broader layer and at the boundary where a device meets a network. We do not do board bring-up.
What is a device platform?
It is everything a fleet needs once the hardware works. Ingestion for the telemetry, storage that keeps years of readings queryable, rules that turn a value into an alarm, provisioning for new units, and a way to deliver firmware over the air without bricking the estate.
What it is not is a dashboard. A dashboard is the visible ten percent. The parts that decide whether the platform survives a fleet growing tenfold are the ingestion path, the storage model and the rollout mechanism.
What we build
Six pieces of a device platform
- Ingestion
- MQTT, CoAP and HTTP, sized for fleets rather than for a demo of ten devices.
- Time series storage
- TimescaleDB and PostgreSQL so a year of readings answers as fast as yesterday's.
- Rules and alarms
- A visual rule engine so your own team changes thresholds without a release.
- Over-the-air updates
- Staged firmware rollout with the ability to stop, which is what makes updating a fleet survivable.
- Identity and tenancy
- Keycloak for single sign-on, with tenants isolated on one deployment.
- Self-hosted deployment
- Docker and Kubernetes, in your own infrastructure, so nobody rents your own data back to you.
What people ask us for
Six device projects we are asked to take on
These arrive most weeks. The first one and the fourth one are the same project seen from two directions.
- Telemetry platform for a fleet
- Readings arriving continuously from equipment, sized for the fleet you will have rather than the ten units on the bench.
- Over-the-air firmware delivery
- Staged rollout with the ability to stop halfway, which is the difference between updating a fleet and gambling with one.
- Instrument integration from a phone
- Reading a device over Bluetooth or a vendor SDK so a value is captured rather than typed. The Hydrajaws build works this way.
- Migration off a SaaS IoT vendor
- Getting the fleet, the history and the enterprise features onto infrastructure you own. This was the IoT Workz project exactly.
- Rules and alarms over data you already have
- Where ingestion works but nothing turns a reading into an action. A visual rule engine lets your own team change thresholds without a release.
- Multi-tenant estate for resellers
- Where your customers each see their own devices on one deployment, with white labelling on top.
Our work
A platform built to be owned, not rented
Case study, IoT platform
Getting off a SaaS vendor without losing the fleet
IoT Workz could not reach enterprise features without tier upgrades, could not white label, and did not own the data. We built a self-hosted platform on ThingsBoard, extended with a white-label layer, Keycloak identity, a visual rule engine, over-the-air firmware updates and multi-tenant isolation. Readings arrive over MQTT, CoAP and HTTP and land in TimescaleDB.
- ThingsBoard
- MQTT
- CoAP
- TimescaleDB
- Keycloak
- Kafka
- Vault
- Kubernetes
- Platform ownership, no vendor lock-in
- 100%
- Critical alarms in live operation on ESP32 fleets
- Zero
- Tenants isolated on one deployment
- Multi
On the device-facing side, the Hydrajaws build reads torque and pull values from instruments through a vendor SDK.
How the work runs
One device talking end to end, early
Week 1 to 2
Protocol and volume
What the devices speak, how often, how many, and what has to be retained. This sizes everything else.
Week 3 to 4
One device end to end
A single unit reporting into a running stack, with an alarm firing, before we build breadth.
Week 5 to 14
Fleet features
Provisioning, tenancy, dashboards, rules and over-the-air updates. Demo every two weeks.
Handover
Run it yourself
Deployed in your infrastructure with pipelines and documentation you keep.
Technology and integration
The stack behind a fleet
All of this is running in production on an ESP32 estate, rather than sitting in a capability list.
- Protocols
- MQTT, CoAP and HTTP for ingestion, sized for fleets rather than for a demo.
- Platform
- ThingsBoard as the base, extended with a white-label layer and a visual rule engine your own team can edit.
- Storage
- TimescaleDB and PostgreSQL, so a year of readings answers as fast as yesterday rather than being rolled up and discarded.
- Streaming and secrets
- Kafka where throughput needs decoupling from processing, and Vault for credentials the fleet depends on.
- Identity and tenancy
- Keycloak for single sign-on, with tenants isolated on one deployment.
- Deployment
- Docker and Kubernetes in your own infrastructure, with Grafana for what operations watches at three in the morning.
Who does the work
Twenty engineers, eight of them senior
Fleet work is unglamorous and detail-heavy. A rollout that cannot be stopped, or storage that quietly discards history, is the kind of mistake that only shows up two years in.
- Engineers in Ho Chi Minh City
- 20
- Senior engineers
- 8
- Average experience
- 5+ yrs
- Working with US, UK and EU teams
- 10+ yrs
You interview whoever we put forward. Ask how they would halt a firmware rollout that is going wrong at forty percent, because that is a real question we have had to answer.
How we work
Five engagement models, and you pick how much you keep
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.
- Team control
- You manage the day to day
- Pricing
- Monthly per person, by role and seniority
- Minimum
- 1 month
A team that works only on your product, with a lead on our side running delivery.
- Team control
- Shared. Our lead runs delivery, you set priorities
- Pricing
- Monthly per role, lead included
- Minimum
- 3 months
A long-term engineering site under your standards, where we carry recruitment, HR, payroll and equipment.
- Team control
- You direct the work, we run operations
- Pricing
- Monthly per role plus site costs
- Minimum
- 6 months
04
Fixed Price
One price for a scope that is genuinely settled, with the overrun carried by us.
- Team control
- We deliver, you accept against written criteria
- Pricing
- Fixed bid, paid against milestones
- Minimum
- Project based, usually 10 to 14 weeks
Everything in the centre model, with the whole team moving into your own Vietnamese entity on an agreed date.
- Team control
- Transfers from us to you
- Pricing
- Monthly per role, transfer price agreed up front
- Minimum
- 2 to 6 years
FAQs
Questions we get on the first call
Do you write firmware?
We build the platform devices report into and the mechanism that delivers firmware over the air, and we integrate with devices through their protocols and SDKs. We are not a board bring-up or driver house. If your project needs that, we will say so and work alongside the electronics team who does it.
Can you get us off a SaaS IoT vendor?
That was exactly the IoT Workz project. The result runs on the client's own infrastructure with no vendor dependency.
How much history can it keep?
Years. We use a time series database so old data stays queryable rather than being rolled up and thrown away.
Can our team change alarm thresholds?
Yes. A visual rule engine means threshold changes do not need a release.
Is over-the-air updating safe on a large fleet?
It is if the rollout is staged and stoppable. That is how we build it, rather than pushing to everything at once.
Who owns it?
You do, including the code and the deployment.
What does a device platform cost, and how long does it take?
One device reporting end to end with an alarm firing is usually four weeks. A working fleet platform with provisioning, tenancy, dashboards and rules takes three to four months. A narrow build, for example instrument reading from a phone with no fleet behind it, is shorter than both. Cost follows the engagement model above, and the scoping call ends with a number.
How large a fleet does this hold?
The architecture is the answer rather than a number we can promise blind. Ingestion decoupled through a broker, time series storage rather than rows in a relational table, and horizontal scaling on Kubernetes. What we can say is that the platform we built runs ESP32 fleets in live operation with zero critical alarms, and that we size ingestion in week one from your protocol, frequency and unit count.
Which chips and boards have you worked with?
ESP32 in production, and instruments reached through vendor SDKs and Bluetooth profiles rather than through the silicon. We integrate with devices through their interfaces; we do not bring up new boards. If your project needs board bring-up we will say so and work alongside the electronics team who does it.
Tell us what your devices send
Protocol, frequency and fleet size are enough to start. Thirty minutes and you will know what the platform needs to look like.