Firmware that survives the real world
Embedded software for connected devices that keep working through power cuts, weak signal and years in the field.
In short
Firmware is where a connected product earns trust or loses it. We write the code that runs on the device: reading the sensors, driving the pumps and motors, talking to the cloud and recovering on its own when something goes wrong. Handee started in 2020 by building a connected hand-sanitiser machine from the board up, so we write firmware knowing exactly what the cloud and the app on the other end expect.
What we build
From the first reading to the last update
The embedded work behind a connected product, scoped to your hardware and to how it will really be used.
- 01
Device firmware
C++ firmware for microcontrollers such as the ESP32, and Python on Linux boards such as the Raspberry Pi, structured so it can be tested, reviewed and changed safely.
- 02
Sensor and actuator control
Reading sensors and driving pumps, motors and relays reliably, like the ultrasonic sensor and 12V diaphragm pump in the Woolworths sanitiser station.
- 03
Connectivity and protocols
Getting data off the device over Wi-Fi or 4G/LTE using MQTT, AMQP or HTTP, with buffering and retries for when the signal drops.
- 04
Power and recovery
Firmware that expects loadshedding: it boots cleanly after a power cut, carries on where it left off and makes the most of every hour on battery.
- 05
Over-the-air updates
An update path designed in from the start, so new firmware reaches devices in the field without a site visit and a failed update doesn't strand a device.
- 06
Security planned with the hardware
Device identity, credential storage and encrypted connections to the cloud, planned alongside the choice of chip rather than bolted on at the end.
End to end
Firmware written by the people who build the cloud
Firmware doesn't live alone. Every reading it sends lands in a cloud service, a database and eventually a screen that someone relies on. When a different supplier owns each layer, the gaps between them are where products fail: message formats drift, retries double-count and nobody owns the bug.
We build all of it. For the Woolworths sanitiser stations, that meant a custom board built around an ESP32 microcontroller and a Simcom SIM7070 4G/LTE modem, the firmware on it, the cloud it reported into and the live dashboard showing usage and online status for every machine.
So when we design a message the device sends, we also design how it's stored, how it's shown and what happens if it arrives twice.
The Handee Method
Faster to the bench, careful in the field
Same small senior team. AI takes the repetitive work: scaffolding, tests, documentation, release checks. Our engineers design, review and stay accountable for what ships.
- 01
Firmware scaffolding
Bring-up code, drivers and message handling are drafted with AI and proven on real boards, so our engineers spend their time on the hard parts: timing, power and failure.
- 02
A working slice in days
The prototype phase produces a firmware skeleton, cloud ingestion, a data model and a working dashboard, validated against real hardware.
- 03
Tested, not hoped
Tests are written with AI as the code is, and every module is reviewed by an engineer before it goes anywhere near a device.
- 04
Documented as it's built
Interfaces and message formats are documented as they're written, so a handover, or a new engineer joining, doesn't mean a rewrite.
The Handee Method
From brief to fleet, in four steps.
Discover
We map the devices, the data they must produce, the systems they plug into and the conditions they must survive.
You get
A scoped build, a plan and a price.
Prototype
We build a working slice first: real firmware on real hardware, a live cloud and a first screen. You hold it in days.
You get
A working prototype on real hardware.
Build
We take it to production: device, cloud and apps, built in short reviewed loops, tested and documented as we go.
You get
Production firmware, cloud and apps.
Run
After launch we run the fleet: device health, anomalies, over-the-air updates and dashboards for your team.
You get
A live fleet, monitored and updated.
Related work
Where our firmware runs
The product Handee was founded on, and the store rollout it became.
Your device
Tell us about your hardware
Tell us about your hardwareA few lines is enough: the board or chip, what the device has to do, where it will live and what's already written. We'll give you an honest view of where the risk is.
- 01Talk directly to the engineers who will write the firmware
- 02Firmware, cloud and apps from one team, so nothing falls between suppliers
- 03An honest view on what to prove on the bench first
What happens next
- 01We read your briefWe come back to you, usually with questions about the hardware and where it will run.
- 02A first callWe talk through the device, its power, its connection and what it must never get wrong.
- 03A clear proposalScope, timeline and cost for a first phase, so you know exactly what you're committing to.
Questions
Firmware questions
What buyers usually ask us before a firmware project starts.
01We already have hardware. Can you write firmware for it?
Yes, and that's often where we start. We work with your board and chipset as they are, and our own products have run on the ESP32 with a 4G/LTE modem. If your hardware uses a microcontroller we haven't shipped on before, we'll tell you plainly in discovery and build that into the plan.
02Can you take over firmware another team wrote?
Yes. We start by getting the existing code building and running on a bench device, then document what it does before changing anything. That shows what's sound, what's risky and what's worth rewriting. You get that assessment first, so decisions about the codebase are made with the facts in front of you.
03How do you handle loadshedding and power loss?
We assume power will fail at the worst possible moment. Firmware is written to boot cleanly, recover its state and reconnect without anyone touching it, and to protect stored data if power drops mid-write. Where a device has to ride through outages, battery sizing is part of the design: the Woolworths stations ran on an 8800 mAh battery pack for up to five days.
04How do firmware updates reach devices in the field?
Over the air. We design the update path in from the start: how new firmware is delivered, how it's checked before it's applied and what the device does if an update fails, so it falls back rather than going dark. Updates can go to a few devices before the whole fleet. Our IoT device management page covers how rollouts are run.
05How do you keep devices secure?
We plan security with the hardware choice, not after it: how each device proves who it is, where its credentials are stored and how its connection to the cloud is encrypted. Features such as secure boot and protected key storage vary from chip to chip, so we'll show you what yours supports and what we recommend using.
06Do you design the hardware too?
We have: the Woolworths sanitiser station ran on a custom-designed board built around an ESP32. Whether we design your board, work alongside your hardware team or build on an off-the-shelf board such as an Arduino or Raspberry Pi depends on your volumes and timeline, and we'll recommend what fits in discovery.