Most embedded product teams expect hardware to be the source of delays. Boards come back with layout issues, components go on long lead times, and a subsystem fails to perform as modelled. These are visible problems with visible causes.
Firmware delays are harder to see coming. They surface late in the embedded product development cycle, when the schedule has no room left, and they are rarely the result of a single bad decision. They are the accumulated consequence of several small decisions made early in the project, often before a line of code has been written.
Understanding where those decisions happen is the first step to making them differently.
In this guide
- Firmware is usually where the schedule slips
- The decisions that cause delays – and when they happen
- What a structured firmware development process does differently
- When does bringing in an external firmware partner help?
- Firmware decisions to make before development begins
- FAQs
Firmware is usually where the schedule slips
A typical embedded product NPI runs from concept to mass production in somewhere between 12 and 18 months for a consumer or industrial device, longer for regulated applications such as medical or aerospace. This timeline varies by product complexity, but the pattern of where delays occur is consistent across project types. Hardware and firmware development are supposed to run in parallel through that timeline. In practice, they rarely do.
Firmware often starts later than planned, because the assumption is that development cannot begin properly until hardware is stable. Testing is treated as a final phase rather than a continuous activity. Requirements that seemed clear at the start of the project turn out to have been ambiguous in ways that only become apparent mid-development. Each of these creates a delay. Together, they create a launch that can slip by weeks or months.
The underlying cause is almost always a process problem, not a talent problem.
The decisions that cause delays – and when they happen
Starting firmware development after hardware is ready
The most common source of timeline slippage in embedded NPI is treating firmware development as downstream of hardware. The assumption is logical: you need hardware to write firmware for. Waiting for stable hardware before starting firmware development means compressing the entire software timeline into the back half of the project, when there is least room to absorb problems.
Experienced embedded teams decouple hardware and firmware development wherever possible. Simulation environments, development boards, and hardware abstraction layers allow meaningful firmware work to begin before the production PCB exists. This parallel development does not eliminate hardware dependency, but it significantly reduces the period during which firmware is on the critical path.
We encounter this regularly in practice. When working with Photon Therapeutics on their UVC infection treatment device, we brought up the operating system and developed the core application while the supplier finalised the operating system which would run it.. Starting that structural work early, rather than retrofitting it later, kept the project on track and avoided the costly rework that deferred architectural decisions typically produce. The client was also able to sign off the GUI before the hardware was ready to show it.
Treating testing as a final-stage activity
Testing at the end of a firmware development cycle is not really testing. It is fault-finding under time pressure, at the point in the project when changes are most expensive and most disruptive.
Bugs found during final integration testing require fixes that can ripple through both code and hardware that has already been reviewed and signed off. If those bugs expose an architectural issue, the cost in time is substantial. A PCB redesign can be even more costly. In embedded development, where hardware and software dependencies create compounding failures, catching problems early matters more than in almost any other development context.
Test-driven development (TDD), continuous integration, and unit testing throughout the development cycle catch problems when they are still small and isolated. Learn more about testing your embedded software project throughout the development process.
The scale of the difference is worth illustrating. On one project involving a 128MB storage device, filling the memory naturally in the field would have taken approximately 21 months. Using a desktop-centric TDD approach, the equivalent test ran in around 13 seconds. When the hardware did arrive, chip drivers were verified quickly and the product moved straight to field trials.Deferring that testing to the end of the project would have made a 21-month validation cycle a hard dependency on the schedule. View our case study to learn more: Debugging Large Embedded Memories in Embedded Programming.
Underspecified requirements
A requirements document that leaves room for interpretation will be interpreted differently by different engineers at different points in the project. Scope creep in embedded development is rarely deliberate. It is usually the result of assumptions that were never made explicit.
The cost of a requirements gap compounds over time. A decision made at week two of development based on an unstated assumption may not surface as a problem until week fourteen, when it has already shaped a significant portion of the codebase. Reworking firmware at that stage is expensive, and it rarely gets done as thoroughly as it should because the schedule pressure is real.
This is not a theoretical risk. We were brought in to investigate a fault on a fire safety curtain system – roller shutter equipment installed at significant cost on client sites – where the curtain would deploy but fail to retract, leaving users trapped. The root cause was a lengthy blocking section introduced by a later developer, which prevented a critical release signal from being polled correctly. The original design guidelines had not been maintained. By abstracting the I/O and running both MCU applications on the desktop, we diagnosed and resolved the fault without a site visit or physical hardware. The cost of that requirements and design drift was substantial. The cost of catching it earlier would have been a fraction of that.
Investing time upfront in a detailed scope and specification document, with a traceability matrix linking requirements to test cases, is not process overhead. It is schedule insurance.
No agreed test plan before development begins
Separate from requirements, a test plan defines what success looks like for each part of the system and how it will be measured. Without one, testing decisions get made reactively throughout development, by individual engineers under pressure, without a shared standard.
An agreed test plan, produced before development begins, creates a shared reference point for what the firmware needs to do, at what level of coverage, and under what conditions. It also makes the project auditable, which matters in regulated industries and in any project where traceability is a contractual requirement.
For Photon Therapeutics, this included contributing to Failure Modes and Effects Analysis (FMEA) before development began, isolating timing-critical and safety-critical code into a compact, analysable codebase, and building traceability in from the start to support future medical device approval. That upfront discipline kept compliance pathways open without inflating development cost at earlier stages of market entry.
Insufficient hardware-software integration testing
Unit testing covers individual components. Integration testing covers how those components behave together and how the firmware behaves with the hardware. This is where embedded systems produce their most expensive surprises.
Hardware-in-the-loop (HIL) testing allows firmware to be tested against a simulated hardware environment before the full system is available, and to run repeatable, automated test suites against it throughout development. Without this, integration failures accumulate silently until final system testing, where they are hardest to resolve.
On an ARINC429 handheld diagnostic tool developed for the aerospace sector, HIL testing allowed us to inject signals into the system and verify subsystems in situ, without needing a vehicle on hand. When the project was later reconfigured as a MIL-STD-1553 diagnostic device, the existing code and test systems were leveraged directly, lowering the total development cost of the second system substantially.
What a structured firmware development process does differently
Teams that consistently hit their NPI dates do not do so because they are faster. They do so because they front-load the decisions that cause delays when left until later. Our embedded firmware development process is built around exactly these principles – requirements and test planning upfront, parallel hardware and firmware development, and testing integrated throughout.
This means agreeing requirements and a test plan before development begins. It means writing firmware in parallel with hardware development, using simulation where physical hardware is not yet available. It means integrating embedded testing throughout the development cycle rather than deferring it. And it means maintaining traceability between requirements, code, and test outputs so that late-stage changes can be assessed and implemented without cascading failures.
On a muscle injury monitoring device developed for a health and fitness client, we leveraged Zephyr OS to bring up the platform quickly, had Bluetooth running in under two weeks, and delivered a verified prototype in under six weeks. That kind of timeline is only achievable when the process is structured from the start, not assembled reactively as the project develops.
When does bringing in an external firmware partner help?
Not every team benefits from an external firmware partner, and it is worth being direct about when it makes sense.
At its simplest, it comes down to two things: a lack of heads, or a lack of specific knowledge. An in-house team might have the people but not the depth in a particular platform, protocol, or OS. Or they might have the expertise but not the capacity, because demand is irregular, a project cannot afford to slip, or the team is already stretched. Either gap is a resourcing issue, not a signal that something has gone wrong with the in-house team.
As Dr Mike Fletcher, Technical Manager at one of our long-standing clients, put it:
“Their expert staff have helped to move projects forward quickly and efficiently, augmenting our own in-house development team. For detailed knowledge and speed of response I thoroughly recommend Peter and the team at Bermondsey.”
What an experienced external team brings in these situations is not just additional capacity. It is a structured approach to firmware development proven across many products and project types, and the ability to integrate into an existing team without disrupting it.
Firmware decisions to make before development begins
The following decisions, made before a line of code is written, have the most significant impact on whether a firmware project hits its NPI dates:
- Requirements scope and sign-off: Have all firmware requirements been documented, reviewed, and signed off by both technical and commercial stakeholders?
- Test plan: Has a test plan been agreed that defines coverage, test types, and pass/fail criteria for each part of the system?
- Hardware/firmware parallelisation: Has a plan been made for how firmware development will proceed before hardware is stable, including simulation and development board strategy?
- Integration testing approach: Has a strategy been defined for hardware-software integration testing, including whether HIL testing is appropriate for this project?
- Traceability: Is there a traceability matrix linking requirements to test cases, so that scope changes can be assessed for their downstream impact?
- Change control: Is there a process for managing requirement changes during development that assesses schedule impact before changes are accepted?
These are not complex questions. They are frequently left unanswered until the project is already under pressure.
If you are planning an embedded product launch and want to talk through your firmware development approach, book a free 30-minute consultation to discuss your project with one of our engineers.
Related blogs
- How to Choose an Embedded Software Development Partner (And the Questions to Ask)
- Best Practices for Thermal Management in Electronics
- Leveraging AI for Predictive Maintenance in Electronics
- Advances in Industrial Control Systems
- Innovations in Sensor Integration for Smart Devices
FAQs
Why is my firmware development taking so long?
Firmware overruns are almost always a process problem rather than a talent problem. The most common causes are starting firmware development too late relative to hardware milestones, treating testing as a final-stage activity, and requirements that were never made explicit enough at the start of the project.
How do I stop firmware delays holding up our product launch?
Front-load the decisions that cause delays when left until later. Agree requirements and a test plan before development begins, decouple hardware and firmware development using simulation and development boards, and integrate testing throughout the cycle rather than deferring it to the end.
What causes embedded NPI timelines to overrun?
The most consistent causes are firmware development starting after hardware is stable, testing treated as a final phase, underspecified requirements, no agreed test plan, and insufficient hardware-software integration testing. Each creates delay independently. Together they compound.
How do other embedded teams hit their launch dates?
Teams that consistently hit NPI dates front-load process decisions rather than making them reactively under pressure. They run hardware and firmware development in parallel, agree a test plan upfront, and use TDD and continuous integration to catch problems early when they are cheap to fix.
When should I bring in an external firmware development partner?
An external firmware partner makes most sense when your in-house team has strong product knowledge but lacks depth in a specific platform, protocol, or OS. It is also worth considering when development demand is irregular and maintaining a full-time embedded team is not economically justifiable. If a project cannot afford to slip and your internal team is already at capacity, bringing in external resource is often faster than hiring. The same applies mid-project, when a process problem needs fixing without stopping development entirely.
What is the best way to structure an embedded firmware development process?
Start with a detailed scope and specification document and an agreed test plan before any code is written. Run firmware development in parallel with hardware using simulation where needed. Integrate testing throughout using TDD and continuous integration. Maintain a traceability matrix linking requirements to test cases so that late-stage changes can be assessed before they are accepted.
How do I reduce risk in embedded product development?
The highest-impact risk reduction measures happen before development begins: clear requirements, an agreed test plan, and a traceability matrix. During development, integrating testing continuously and using HIL testing for hardware-software integration catches failures when they are still small and isolated rather than at final system testing when they are most expensive to resolve.
How long does embedded product development take?
For a consumer or industrial device, a typical embedded product NPI runs from concept to mass production in somewhere between 12 and 18 months. Regulated applications such as medical or aerospace devices typically take longer. The timeline varies by product complexity, but firmware process failures are the most consistent cause of projects running beyond their planned schedule.
