Device firmware and edge software
The firmware is the part you cannot patch from a laptop once ten thousand units are on customer sites. We treat it as the highest-stakes code in the project and write it accordingly.
Most connected products get into trouble here first. A sampling rate is chosen because it sounded reasonable, the radio is picked before anyone has measured the site, and the update path is left until after the launch date. Two years later the fleet is stranded on a build nobody can safely replace.
What the work actually involves
What we build
- Sensor drivers and calibration routines, with the calibration data stored on the device rather than in a spreadsheet
- Sampling schedules and local thresholds so a device can act without waiting for the cloud
- Store-and-forward buffers sized to the worst outage you are willing to survive
- A signed OTA client with rollback, staged rollout support and a health check that reverts a bad image
- Secure element integration so private keys are generated on-device and never leave it
- Manufacturing test firmware and a jig protocol the factory can run without our help
How we de-risk it
- Power budget modelled in week one, then measured on real silicon before the enclosure is designed
- Radio range and interference surveyed on the actual site, not in the office
- Renode simulation in CI so firmware regressions are caught without a hardware lab
- Fault injection: pulled antennas, brownouts, corrupted flash, clock drift, full buffers
- Every build reproducible and signed, with the toolchain pinned in the repository
What you get to keep
- Firmware source in your repository, with a documented build
- Power budget with measured figures, not estimates
- Provisioning and manufacturing test procedure
- OTA rollout runbook including the rollback path
- Threat model covering device identity and update integrity
No. We write firmware and work alongside your electronics team, or one of the contract manufacturers we partner with. We will review schematics for anything that affects firmware — test points, boot straps, secure element placement, current measurement — before the board is spun.
Zephyr when the product will outlive a single silicon vendor, ESP-IDF when the ESP32 family is already chosen, and bare-metal only when the power budget genuinely demands it. The decision is made in discovery and written down with the reasoning.
What this normally sits next to
These capabilities come up in almost every engagement that includes the one above.
Cloud, deployment and monitoring
Infrastructure as code, one-command environments, and dashboards that page a human before a customer notices. We hand you the keys and the runbook, or keep running it for you.
Node.js ingestion and services
An MQTT front door, a device registry, a rules engine and clean HTTP and WebSocket APIs. Written in TypeScript, sized to your message rate, and load tested with a simulated fleet before real hardware arrives.
Talk to the engineers who do this work
The first call is with whoever would lead the build, not an account manager. Bring the constraint you think is going to be a problem.