Services
Engineering for every layer of a connected product.
Four service lines, one team. Pick the layer where you need help, or hand us the whole stack.
01 · Embedded
⚙ Embedded systems
From first power-on to a reproducible production image. We bring up boards, write the firmware and bootloaders, and build the board support package your product will be maintained on for years.
Typical engagements
- Bring-up of a new board or SoC, with a written bring-up log your team can repeat
- A Yocto or Buildroot BSP with secure boot, A/B updates and a CI pipeline that produces signed images
- Firmware for a Cortex-M or RTOS-based device, including power budgets and a hardware-in-the-loop test rig
Capabilities
- Firmware development, bare-metal and RTOS-based (Zephyr, FreeRTOS, ThreadX)
- BSP development with Yocto, Buildroot and OpenWrt
- Board and SoC bring-up: clocks, pinmux, device trees, peripheral validation
- U-Boot, Arm Trusted Firmware and UEFI/EDK2 bootloaders with verified boot
- Secure boot chains, dm-verity, LUKS/dm-crypt and hardware-backed key storage
- Embedded security: TrustZone, OP-TEE, TPM and secure elements
- Low-power design: sleep states, wake sources, measured power budgets
- Hardware/software co-design and schematic review from the firmware side
What you receive
Source in your repositories, a reproducible build (one command from clean checkout to flashable image), a bring-up and configuration guide, and a test plan that runs on real hardware.
02 · OS & middleware
⚡ OS, drivers & middleware
The layer where most connected products actually break: kernel drivers, bus stacks, the protocol and IPC code that ties hardware to services. We write it, port it and fix it, on Linux, Windows and RTOS targets.
Typical engagements
- A Linux driver for a new peripheral, upstream-quality, with device-tree bindings and tests
- A Windows kernel-mode driver (KMDF, NDIS, StorPort or WDDM miniport) for hardware that only had a Linux driver
- An OTA client, protocol stack or device SDK that has to run identically on three generations of hardware
Capabilities
- Linux kernel drivers and subsystems: USB/xHCI, PCIe, SDIO, network, storage, GPIO/I²C/SPI
- Windows kernel-mode drivers: WDM, KMDF, NDIS, StorPort, WDDM, and NT internals
- Multi-core bring-up and SMP correctness: interrupt controllers, memory ordering, lock design
- Communication stacks: MQTT, CoAP, gRPC, AMQP, custom binary protocols over serial and radio
- IPC and message buses: D-Bus, ZeroMQ, shared memory, lock-free queues
- OTA update clients and update-orchestration logic (Mender, RAUC, SWUpdate, custom)
- OS abstraction layers, portability frameworks and cross-platform C/C++ SDKs
- Compatibility layers and emulation: Wine, ReactOS, FEX-based x86-64 on ARM64
What you receive
Reviewed, documented driver or library code in your tree, a test suite that exercises the hardware paths, and a design note explaining the locking, DMA and error-handling decisions so the next engineer does not have to reverse-engineer them.
03 · Cloud
☁ Cloud platforms for device fleets
Backends designed by people who also write the device side. Device identity, telemetry, fleet management and OTA rollout services that stay correct when devices lose connectivity, reboot mid-update or come back after six months offline.
Typical engagements
- A device platform on AWS IoT Core or Azure IoT Hub: provisioning, shadows/twins, telemetry, alerts
- An OTA service with signed artefacts, staged rollouts, automatic rollback and an audit trail
- A self-hosted MQTT and time-series stack for teams that cannot send data to a public cloud
Capabilities
- IoT backend architecture and device management platforms
- Device identity and provisioning at scale: X.509, mTLS, certificate rotation, secure element integration
- Telemetry ingestion: MQTT brokers (EMQX, Mosquitto), stream processing, time-series storage
- OTA server infrastructure, rollout orchestration and fleet-wide health dashboards
- Cloud-native microservices on Kubernetes, with infrastructure as code
- Multi-cloud, hybrid and on-premises deployments for regulated environments
- Security, access control and compliance for connected-device data
- Monitoring, observability and alerting (Prometheus, Grafana, structured logs)
What you receive
Infrastructure and services defined as code in your cloud account, runbooks for operations, dashboards for fleet health, and load-tested capacity numbers instead of guesses.
04 · Rescue & performance
🔍 Rescue, debugging & performance
For products that are already shipping and misbehaving. We build a reproducible rig, find the root cause, fix it and leave a regression test behind. No guessing, no “works on my board”.
Typical engagements
- A one-to-three-week diagnostic sprint on a crash, hang or data-corruption bug, ending in a written root-cause report
- Throughput or latency work on a Wi-Fi, Ethernet, USB or storage path that is far below the datasheet
- Boot-time, memory-footprint or battery-life reduction with before/after measurements
Problems we take on
- Kernel panics, bug checks and silent resets that only appear under load or on multi-core parts
- DMA and cache-coherency corruption, use-after-free and lock-ordering bugs
- USB, PCIe and SDIO devices that fail to enumerate, drop off the bus or stall
- Network throughput stuck far below the link rate; interrupt storms; packet loss
- Slow boot, slow resume, memory growth in long-running devices
- Driver breakage after a kernel, compiler or toolchain upgrade
- Emulation and compatibility-layer faults (x86 on ARM64, Windows binaries on non-Windows kernels)
What you receive
A reproduction recipe, a root-cause analysis with evidence (traces, captures, disassembly where needed), the fix as a reviewed change in your tree, and a regression test that fails before the fix and passes after.
Engagement models
Three ways to work with us.
Diagnostic sprint
1 to 3 weeks · fixed price
One well-defined problem, one written answer: the root cause, the fix or the plan to get there, and what it will cost. Ideal when you need certainty before committing budget.
Fixed-scope project
Weeks to months · milestones
A BSP, a driver, a platform, a migration. Scoped in writing with acceptance criteria per milestone, demoed on real hardware, and handed over with documentation and tests.
Retainer / team extension
Ongoing · monthly
Senior embedded, kernel or cloud capacity inside your team: code review, on-call for hard bugs, architecture guidance and hands-on delivery, with a monthly written summary.
Every engagement includes
- NDA first. Signed before you share schematics, code or roadmaps.
- Your repositories, your CI. Nothing lives only on our machines.
- Weekly demo on real hardware. Progress you can see, not a status slide.
- Written decisions. Design notes and root-cause reports ship with the code.
- Handover included. Documentation, tests and a knowledge-transfer session at the end.
How we think about these problems
Recent articles from the engineering blog.
- Bringing an OS up on Raspberry Pi 5: what the RP1, PCIe and the GIC demand from your kernelNotes from an ARM64 kernel bring-up on the Raspberry Pi 5: almost every peripheral sits behind a PCIe link, DMA is not coherent with the CPU caches, MSIs go through the GIC ITS, secondary cores arrive at EL2, and one xHCI flag decides whether USB bulk transfers ever complete.
- ARM64 SMP bugs are memory-ordering bugs until proven otherwiseCode that ran for years on x86 falls over one boot in fifty on a four-core Cortex-A76. The six patterns behind almost every such failure we have chased, the barriers that fix them, and why QEMU on a laptop will hide all of them.
- Where the packets per second go: SDIO Wi-Fi throughput on a Broadcom CYW43455A Wi-Fi link that tops out around one megabit with an idle CPU is not a radio problem. Six host-side causes, from missing receive glomming to a byte-mode CMD53 bug, and how to count SDIO transactions per packet before touching anything else.
Have a project in mind?
Tell us what you are building or what is broken. We reply within one business day.