Embedded software and IoT development that survives the field.
Firmware in C, C++ and Rust for ESP32, STM32 and Nordic nRF microcontrollers - plus everything the device talks to: the radio link, the server, updates over the air and the dashboard your team actually opens. From a breadboard prototype to a small series that runs unattended.
- Firmware in C, C++ or Rust - bare metal, FreeRTOS or Zephyr, chosen per project.
- Wi-Fi, Bluetooth, LoRaWAN or cellular - picked from range, power budget and data volume.
- Signed updates over the air, with automatic rollback if one fails.
- One team for device, server and dashboard - nobody to blame at the interface.
Gaps designed, not discovered
IoT projects rarely fail on the sensor. They fail in the gaps: a device that drops off Wi-Fi and never comes back, an update that bricks half the fleet, a battery meant to last two years that lasts four months. We write the firmware and the systems around it as one piece, so those gaps get designed instead of discovered.
We work with the chips products actually ship on: ESP32 when Wi-Fi or Bluetooth and a low unit cost matter, STM32 for real-time control and lots of peripherals, Nordic nRF52 and nRF91 for Bluetooth and low-power cellular, and Arduino-class boards for a prototype you can hold next week. Server side: an MQTT broker, a backend for readings and alert rules, and a fleet view with device health and firmware versions.
We are a software studio, not a contract manufacturer: we write firmware, build prototypes and bring up boards. PCBs at volume come from an electronics manufacturer of your choice, and we hand them the production firmware and test procedure.
How it works
What a connected device does for you
Three things a well-built sensor system does, shown in a food distributor’s cold rooms.
-
Someone leaves the cold-room door open. The temperature climbs, and the manager’s phone buzzes long before the stock is at risk - not the next morning.
-
The sensor sleeps almost all the time and wakes only to send a reading. Reporting every 15 minutes instead of every minute turns months of battery into years.
-
A new firmware version reaches every sensor remotely. If an update fails on one device, it rolls back to the old version and keeps working.
In practice
Illustrative scenarios - the kind of work we take on, not client case studies.
Cold-room monitoring for a food distributor
- The problem
- Walk-in cold rooms are logged by hand twice a day. A compressor that fails overnight is discovered in the morning, together with a pallet of spoiled stock.
- What we build
- Battery probes on nRF52 report over Bluetooth to a gateway every minute; the gateway forwards to the server. Alert rules with a delay, escalation by SMS and email, an export for food-safety audits, and updates through the gateway.
- nRF52
- Zephyr
- BLE
- MQTT
- PostgreSQL
- SvelteKit
Retrofitting older production machines
- The problem
- A workshop runs machines without any network interface. Nobody knows the real utilisation, and maintenance is scheduled by calendar instead of run hours.
- What we build
- A small ESP32 box per machine reads a clamp-on current sensor, counts run hours, buffers locally when Wi-Fi drops and reports to a server on site. A dashboard shows utilisation per shift and flags machines due for service.
- ESP32
- ESP-IDF
- C
- MQTT
- TimescaleDB
- Grafana
Tank level sensors with no power and no Wi-Fi
- The problem
- Water tanks spread over several sites are checked by driving out to them. There is no mains power at the tanks and no Wi-Fi in range.
- What we build
- Ultrasonic level sensors on an STM32 with a LoRaWAN radio, asleep between readings, reporting every 30 minutes and sooner when the level moves fast. The battery budget is calculated up front and checked on the bench.
- STM32
- LoRaWAN
- C
- ChirpStack
- Node.js
- PostgreSQL
What you get
- Firmware source in your repository, with a reproducible toolchain
- Bring-up notes: pin map, power rails and the quirks we hit
- Working prototypes on dev kits or your board, flashed and tested
- Updates over the air: signed builds, staged rollout and rollback
- A written spec of every message the devices send
- Fleet dashboard: last seen, signal, battery, firmware version and alerts
- A measured power budget and battery estimate
- Production flashing and test procedure for your manufacturer
Typical stack
- C
- C++
- Rust (Embassy)
- ESP-IDF
- FreeRTOS
- Zephyr
- STM32Cube
- nRF Connect SDK
- Arduino
- PlatformIO
- MQTT
- LoRaWAN
- BLE
- TimescaleDB
Questions people ask
Your question is not on the list? Ask us directly - we reply within two working days.
Ask a questionHow much does IoT or embedded software development cost?
It depends on how much is new. The main drivers are the number of sensors and interfaces, the radio and power requirements, whether you need updates over the air and a fleet backend, and whether the device needs radio certification (we prepare the firmware; an accredited lab does the testing). After a 30-minute intro call you get a written plan and a fixed-scope estimate - usually with the prototype priced as its own phase.
How long does it take to build an IoT prototype?
Mostly on the hardware. Off-the-shelf sensors on a dev kit move fast; a custom board needs design, fabrication and usually a revision, and each round takes weeks on its own. We plan in phases - proof of concept on dev kits, then your hardware, then a small series - and the written plan gives you a date for each.
ESP32, STM32 or nRF - which microcontroller should we use?
ESP32 for Wi-Fi or Bluetooth at a low unit cost, when the power budget allows Wi-Fi. STM32 for motor control, precise timing, many peripherals or an industrial temperature range. Nordic nRF52 for Bluetooth at very low power, nRF91 for LTE-M or NB-IoT. Availability and certified radio modules weigh in too. You get a recommendation with the reasons written down.
Can you take over existing firmware or an Arduino prototype?
Yes. We start with a short audit: make it build reproducibly, then measure what it actually does - memory, power draw, what happens when the network drops. Arduino prototypes are a fine starting point; we keep what works and move the rest to a production-grade setup, adding updates over the air, logging and a watchdog.
Do you also design and manufacture the hardware?
We build prototypes, bring up boards, write production firmware and review schematics from the firmware side. PCB design for volume, enclosures and assembly are done by a hardware partner or electronics manufacturer. We give them the production image, a flashing and test procedure, and a way to give every unit its own identity and keys.
Tell us what your device has to do.
What it measures, where it lives and how it gets power is enough to start. We reply within two working days with a link to a 30-minute intro call.
Start an IoT project