Every year or so, a client asks us a question we did not expect to be answering when we started: "can you build the thing that collects the data?" It is a good question. The data problem and the silicon problem are increasingly one problem, and we have built an Engineering Services capability — embedded software, firmware, FPGA and limited custom-silicon work — because the boundary between "the data platform" and "the device that generates the data" kept moving.
Three places the boundary actually matters
1. Edge AI in sensor-rich environments
Manufacturing lines with dozens of vision sensors. Housing stock with hundreds of humidity sensors. A water utility's network with thousands of acoustic leak detectors. The data rate is too high to send raw to the cloud; the inference value is too high to skip. The right architecture runs inference at the edge — on a microcontroller, an edge accelerator, or an FPGA — and sends structured results upstream.
This is a genuine engineering problem. Model compression, quantisation, on-device evaluation, OTA update pipelines, power budgets, thermal behaviour. It is not "download a model and flash it"; it is a discipline.
2. Legacy integration where the machines do not speak
Manufacturing plants with equipment that predates OPC UA. The choice is replace-the-equipment (capex) or bolt-on-telemetry (engineering). Bolt-on means reading current sensors, vibration probes, temperature sensors, sometimes visual markers, and publishing clean telemetry upstream. This has been 20–30% of our Engineering Services work in 2025.
3. Differentiated devices where vendors do not exist
Occasionally a client's product is the data. Specialty scientific instruments, bespoke IoT, a novel sensor for a regulated application. Off-the-shelf does not exist; the incumbent vendor is slow. Our smallest silicon engagements are here — FPGA-based signal-processing designs, custom PCBs with a microcontroller and a well-chosen sensor stack, and in two cases so far, a small semi-custom ASIC collaboration through a partner foundry.
What we actually do — and do not do
To set expectations clearly:
- We do: firmware (C, Rust, embedded C++), RTOS work (FreeRTOS, Zephyr), edge ML (TFLite, ONNX Runtime, executorch), bare-metal development on Cortex-M and RISC-V targets, FPGA design (Verilog/VHDL, typically Xilinx/AMD and Altera/Intel), PCB design, design-for-manufacture support, sensor integration, and edge-to-cloud telemetry.
- We do selectively: custom-silicon work, through partner foundries and IP blocks. We are candid with clients that this is a specialist path and usually the wrong one.
- We do not do: consumer-electronics volume manufacturing, certification-heavy medical devices as the principal, or safety-critical automotive. We bring specialists in where those requirements appear.
When you should build custom silicon
Almost never. The cases that actually warrant it:
- Volume is high enough that per-unit cost and power margin dominate the business case
- The signal-processing is latency- or energy-critical and cannot run on available microcontrollers or FPGAs
- There is genuine IP protection value in the silicon
- Time-to-market is not the constraint; custom silicon is a multi-year path
For the overwhelming majority of embedded projects, an ARM microcontroller or an FPGA, well-chosen, is the right answer. Our job is often talking clients out of a custom-silicon decision.
The edge-ML discipline
Edge ML looks like a reduced version of cloud ML. It is not. The constraints are very different:
- Models must be quantised, sometimes to 8-bit or 4-bit weights
- The evaluation must include on-device timing and memory, not just accuracy
- The OTA update path must be atomic, with rollback
- Security (secure boot, signed firmware, attestation) must be designed in
- Power budgets are often tighter than data scientists anticipate
When we ship an edge-AI programme, it is always joint between the AI team (who own the model) and the engineering team (who own the device). Treating them as separate projects fails.
Where this sits in a broader programme
Engineering Services rarely stands alone. It is usually one phase of a larger data strategy: the manufacturing client also has an OEE programme; the housing association also has a damp-and-mould programme; the water utility also has a cloud analytics platform. The device is the ground truth; the platform is where the value compounds. We operate both.
A short checklist before building a device
- Is an off-the-shelf device fit for purpose, even with integration effort?
- If we build, what is the volume and the unit economic target?
- What is the certification path (CE, UKCA, FCC, sector-specific), and who owns it?
- What is the OTA strategy on day one?
- What is the security baseline (secure boot, TLS, attestation, key management)?
- What is the end-of-life strategy? Firmware cannot be supported forever; plan the decommissioning.