Most hardware companies make this decision once, under time pressure, without a clear framework for what actually matters. We have been on the engineering side of enough of these engagements to know what separates a partnership that ships from one that stalls.
Discuss Your ProjectFirmware engineering is a narrow discipline. The pool of engineers who can bring up a BSP on an unfamiliar SoC, write a reliable flash storage layer, and also reason carefully about real-time scheduling constraints on a constrained device is smaller than most hardware founders expect. When you add domain requirements — medical device, industrial, consumer connected — the overlap narrows further.
The consequence is that many hardware companies end up evaluating firmware partners primarily on availability and price, because the technical criteria are hard to assess quickly. That is understandable, but it tends to produce engagements where the partner can code but cannot navigate the specific problems your hardware will surface. Firmware bugs on shipping silicon are expensive. Bring-up delays when a new board revision arrives set timelines back weeks. A partner who has done this before on similar hardware and similar constraints is worth considerably more than one who is technically capable but learning on your project.
The questions that actually matter when evaluating a firmware partner have less to do with headcount or tool certifications and more to do with how they approach the parts of the work that go wrong — because something always goes wrong on a new hardware bring-up.
"Firmware bugs on shipping silicon are expensive. The partner learning on your project is a risk most hardware schedules cannot absorb."
The failures we see most often are not catastrophic. They are slow. A bring-up that takes three weeks instead of one because the partner is unfamiliar with the toolchain. A flash storage implementation that works in development but develops wear issues in field units at six months. An OTA update system that handles the happy path cleanly but corrupts device state on an interrupted update. A test suite that covers unit behaviour but misses the timing interactions that only appear under real load.
None of these are caused by incompetence. They are caused by a partner who has not encountered this specific class of problem before and is solving it for the first time on your schedule. The most useful question to ask any firmware partner is not what they have built — it is what broke, and how they found it.
Board Support Package bring-up is the first real test of a firmware partner's capability. It is the work of getting a new hardware platform to a state where higher-level software can run reliably — initialising peripherals, validating clock configurations, getting the bootloader stable, confirming that the hardware abstraction layer behaves as the datasheet describes. On a new SoC or a custom board revision, this is often where engagements lose weeks. A partner who has brought up hardware on a similar platform — same silicon family, similar peripheral set — will move significantly faster than one who is reading the reference manual alongside you.
We do BSP bring-up regularly across a range of platforms. The discipline is the same regardless of the silicon vendor: read the errata carefully, validate each peripheral independently before integrating, and never assume the datasheet is complete. The difference between a one-week bring-up and a three-week bring-up is usually one or two errata items that are not obvious until you have seen them before.
Flash storage is one of the most consequential firmware decisions on a connected device and one of the least visible until it fails. Wear levelling, erase block management, and power-loss recovery behaviour all need to be explicitly designed for. NAND flash in particular has failure modes that only manifest after extended field use — and if the storage layer has not been designed with those modes in mind from the start, fixing them in a shipped product is a firmware update that carries its own risk.
For products where storage reliability is critical — industrial devices, medical wearables, fleet-connected hardware with high write frequency — we treat the storage architecture as a first-class design decision, not an implementation detail. The choice of filesystem, the write coalescing strategy, and the fallback behaviour on corruption need to be deliberate and tested under simulated failure conditions before hardware leaves the lab.
Connected devices operating in industrial environments have constraints that consumer IoT does not. Intermittent connectivity, long periods without a network, voltage fluctuations, electromagnetic interference, and the expectation of multi-year field life without physical access for maintenance all change the engineering requirements considerably. Connectivity stacks that behave well in a lab can be fragile in the field. Message queuing, reconnection logic, and local storage for buffering telemetry during network absence need to be designed for the actual environment, not the typical case.
Industrial IoT is a meaningful part of our embedded work. The field conditions that break connectivity stacks are well understood problems — they just require deliberate design and field-representative testing to handle properly.
Over-the-air firmware update is one of those features that appears straightforward until a field update goes wrong and a device in a remote installation is left in an unrecoverable state. The requirements for a robust OTA system are well established: atomic updates, verified rollback, integrity checking before commit, and behaviour that is safe on interrupted power. What varies is whether the partner has built this before or is implementing it for the first time. A first implementation under delivery pressure tends to handle the happy path and miss the edge cases. The edge cases are the ones that matter in the field.
"The requirements for a robust OTA system are well established. What varies is whether the partner has built this before or is implementing it for the first time under deadline."
Firmware testing is genuinely difficult. The hardware and software are interdependent in ways that make unit testing alone insufficient. Timing behaviour, interrupt latency, peripheral interactions, and power state transitions all need testing in conditions that approximate the real device. Most firmware engagements give testing a fraction of the time it warrants, because it is easy to underestimate until a field issue surfaces.
The partners worth working with have a testing methodology that goes beyond running the firmware on a development board and observing that it works. Hardware-in-the-loop testing, fault injection for power failure and connectivity loss scenarios, and endurance testing for flash wear are the kinds of work that prevent the slow failures described earlier. They are also the work that most budget-constrained engagements skip — which is why we are direct about it in scoping conversations. Skipping testing is a cost transferred to field maintenance and hardware revision cycles, not a saving.
The most revealing questions are specific. Ask how they test interrupt-driven code. Ask what their process is for validating flash behaviour under power loss. Ask how they handle regression testing when hardware changes between revisions. Ask what monitoring they put in place for field-deployed devices. A partner with real depth in this area will answer these questions with specifics. A partner who is adequate but not experienced will describe a reasonable-sounding process that turns out to be mostly manual.
These questions do not require the partner to have passed a certification. They require them to have done the work. The answers will tell you more than a capability brochure.
Firmware development works best when the partner is closely integrated with the hardware team, not operating at arm's length. The feedback loop between hardware behaviour and firmware response is tight — a peripheral that does not behave as the datasheet describes, a power rail that is noisier than expected, a timing assumption baked into the firmware that the board does not satisfy — all of these require fast iteration between the people writing the firmware and the people who designed the board.
Engagements where the firmware partner is handed a specification and asked to deliver against it without ongoing hardware access tend to accumulate problems that only surface during integration. The specification is always incomplete. The hardware always has surprises. The question is whether the partner is close enough to the hardware to find those surprises early or whether they discover them at bring-up when the schedule has no room left.
We work as part of the product team rather than as a separate delivery track. On embedded projects that means direct access to hardware, direct communication with the electrical engineers, and involvement in board revision decisions where firmware constraints are relevant. That is not a preference — it is what makes the firmware reliable.
For hardware products in regulated domains — medical devices, industrial equipment, products that need IEC 62443 or DO-178 compliance — the firmware engineering requirements go beyond what a general embedded partner can cover. Traceability from requirements to test cases, documented development processes, specific coding standards, and the ability to support a verification and validation exercise are all requirements that need to be confirmed before an engagement starts, not discovered mid-project when the regulatory submission timeline is set.
If your product has any regulatory dimension, that conversation needs to happen in the first meeting with any firmware partner you are evaluating. It is not a detail.
We are a software engineering services company. Our embedded engineers work as part of your product team — from bring-up through field deployment — on the problems described above.
Bring-up on new hardware platforms, flash storage architecture, RTOS and bare-metal development, OTA update systems, and connectivity stacks for industrial and consumer IoT.
Hardware-in-the-loop testing, fault injection, endurance testing for flash and storage, regression testing across board revisions, and field diagnostic instrumentation.
Firmware engineering for products with regulatory requirements — traceability, documented development process, coding standards, and support for V&V activities.