Field guide № 04 — Hardware & IoT teams

From bare metal to the cloud dashboard — one team, no handoffs.

The firmware contractor vanished after v1.0. The device team and the app team meet only in the bug tracker. And the estimate grew a decimal place since the prototype. We take hardware products from bare metal to the cloud as one team — deliberately, and in writing.

For hardware startups, product companies, and engineering teams building sensors, controllers, and connected devices.

§ 01 — What we work on

The whole stack,
soldered to shipped.

Firmware, edge software, connectivity, and the cloud companion — the layers your device needs, engineered by people who have shipped all of them.

Firmware

ARM Cortex-M, RISC-V, and ESP32 targets in C, C++, or Rust — chosen for the job, not the fashion. Power budgets, watchdogs, and field diagnostics treated as first-class requirements.

Embedded Linux

Board bring-up and application software on embedded Linux — Yocto and Buildroot images that build reproducibly and update safely in the field.

Connectivity

BLE, LoRa, and MQTT integrations that survive real-world radio conditions — with the retry logic, buffering, and security that demo firmware always skips.

Cloud companions & fleets

The dashboard, mobile companion, and fleet management your device needs to be a product rather than a gadget — plus OTA updates you can ship without holding your breath.

§ 02 — Field record

Named clients are rare
in this bed.

Hardware work is usually under NDA, so this section trades names for specifics. Representative engagements, described honestly.

Sensor firmware, years in the field

Low-power sensing firmware on ARM microcontrollers, running unattended on batteries measured in years — with remote diagnostics that made site visits the exception.

Edge Linux with a cloud twin

Embedded Linux devices paired with a cloud companion for fleet monitoring, configuration, and staged OTA rollouts — one codebase from the board to the browser.

Rescue and takeover work

Inherited codebases from departed contractors, brought under test, documented, and shipped — the least glamorous work we do, and some of the most valued.

§ 03 — Hardware in the loop

The rig, not just
the firmware.

Bench is our hardware-in-the-loop test rig — a physical fixture, the firmware that runs it, and a Python test framework that drives the whole thing, turning the hardware checks teams do by hand into tests that run on every build. We build it around your device.

See the rig — Bench →
§ 04 — How an engagement runs

No packages.
A process instead.

Embedded work priced off a menu is a warning sign. Ours runs in three steps, and the first one exists to make the second one honest.

№ 01 — Fixed fee

Scoping sprint

One to two weeks, fixed price — from $4,500 NZD (indicative, + GST). We review your architecture and constraints, build a risk register, and produce an estimate you can hold us to. If the honest answer is that you don’t need us, that’s the deliverable.

№ 02 — Milestone priced

Fixed-scope build

Priced from the sprint’s findings, delivered in milestones you can test on real hardware — not slideware. You see working firmware on your bench at every checkpoint, and the estimate doesn’t quietly drift.

№ 03 — Ongoing

Retainer

Firmware maintenance, OTA releases, and cloud operations after launch — because devices in the field don’t stop needing engineering when the project ends. Slow at the start, sturdy at the finish.

§ 05 — Common questions

Asked at the
bench.

C, C++, or Rust?

Whichever the constraints choose. Rust where memory safety pays its way and the toolchain supports your target; C or C++ where the ecosystem, vendor SDKs, or your existing codebase make them the pragmatic call. We hold no religion on this, only preferences backed by shipped projects.

Can you take over an existing codebase?

Yes — takeovers from departed contractors are a recurring part of our work. We start by getting it building reproducibly and under version control, then bring it under test before changing behaviour. You get an honest written assessment of what you have before we touch it.

Do you support certification (CE, FCC, RCM)?

We build firmware with certification in mind — RF duty cycles, emissions-relevant behaviour, and test modes for the lab — and work alongside your certification house. We are engineers, not a test lab, and we will say so where the boundary sits.

Do you sign NDAs?

Yes, routinely — most hardware work on this page is described without names for exactly that reason. Send yours, or we can supply a mutual NDA to start from.

Can you work alongside our electrical engineers?

That is the arrangement we like best. We slot in beside your EE team from schematic review onwards — firmware decisions and hardware decisions are cheaper when made in the same room.

§ 06 — Contact

Tell us what
you're building.

We read every enquiry ourselves and reply within two working days. Quick chats, long briefs, half-formed ideas — all welcome.

Send a short note about the device, the target hardware if it's chosen, and where the project stands — napkin, prototype, or field failures. If an NDA needs to come first, say so and we'll start there.