Engineering services

Hardware, firmware and cloud, built to work as one system.

Most connected-equipment projects fail at the seams — the board talks, the cloud listens, and nobody owns what happens in between. We take the whole path, from the signal on the wire to the fleet tool your support team uses.

Capabilities

What we take on.

Embedded hardware

ESP32 and ESP32-S3 board design for equipment that has to survive a real site: sensing, power, I/O and the cable harness that connects it to the machine. Prototypes through to small-batch production, assembled and bench-tested before they ship.

Firmware

C++ on ESP-IDF, written on our own HSYS framework: modular, message-based, with a hardware abstraction layer so the same code runs as a desktop simulator. Behaviour gets tested before a board is powered up, and products share one codebase.

Protocol reverse engineering

Equipment that was never meant to be read usually still says something on a wire. We capture it, decode it, and build the tap that turns it into usable events — as we did for three different fuel dispenser display protocols.

Cloud integration

HTTPS for telemetry, MQTT for the command and configuration path. Device identity, reconnection and local buffering handled on the board, so an unreliable link delays data rather than losing it.

OTA update pipelines

Versioned update bundles delivered over MQTT or HTTP, applied in a safe order and rolled out in batches. Staged updates for multi-chip boards, where boot, partition and firmware must land in sequence.

Fleet and factory tooling

The unglamorous half that decides whether a deployment is supportable: a support console for the fleet, remote config with snapshots and audit trail, factory flashing scripts, log collection, and test rigs that emulate the real equipment.

Working with us

How an engagement usually runs.

Scoped in stages, so you can stop at the end of any one of them with something usable in hand.

Understand the equipment

What the machine is, what it already emits, and what you need out of it. Often a short capture-and-decode exercise on a live unit before anything is committed.

Prototype on the bench

A working board and firmware against a test rig or a real unit, proving the signal can be read reliably and the data lands where it should.

Pilot on site

A small number of units installed and watched in production conditions — which is where the surprises actually surface.

Roll out and support

Batch production, installation, and the tooling for whoever supports the fleet afterwards. Updates ship over the air from then on.

Good fit

Where we are genuinely useful — and where we are not.

A good fit

  • Industrial or retail equipment that should be reporting and isn't
  • Legacy machines with no API and no vendor support
  • Small to mid-size fleets that need remote support to be practical
  • Projects where one team should own board, firmware and cloud
  • Long-lived deployments that will need updates for years

Probably not us

  • High-volume consumer electronics manufacturing
  • Safety-certified control systems requiring formal certification
  • Pure web or mobile app work with no hardware involved
  • Very large fleets needing a dedicated 24/7 support desk

Tell us what the machine is.

A short description of the equipment and what you want out of it is enough for us to say whether this is worth a conversation.