A hardware timeline built by estimating engineering effort alone — design time, firmware development time — routinely comes in far short of reality, because a large share of the actual calendar time between prototype and production is spent on things that aren't engineering work at all: component lead times, fabrication and assembly turnaround, certification cycles, and validation testing. A realistic estimate accounts for all of these explicitly, not just the parts that feel like "the work."
The stages that make up the real timeline
- Schematic and layout design — the engineering-heavy phase most estimates focus on, and the one most within the team's direct control
- Component sourcing and lead time — some components, particularly specialized ICs or anything affected by supply constraints, can have lead times measured in months, and this needs checking before, not after, finalizing a design around them
- PCB fabrication and assembly — typically one to a few weeks per cycle depending on board complexity and the fab house, and this cycle repeats every time a design revision is needed
- Bring-up and debug — the first working prototype rarely works perfectly; time for hardware/firmware bring-up and fixing what doesn't work needs to be budgeted, not treated as a contingency
- Design validation testing — verifying the design meets its actual requirements (environmental, mechanical, electrical) under realistic conditions, not just bench testing in ideal conditions
- Certification (FCC/CE/UL and similar) — its own multi-week-to-multi-month cycle, ideally overlapped with other work rather than treated as strictly sequential, but still real calendar time
- Manufacturing ramp — the transition from a small pilot run to full production volume, including tooling, line setup, and the first-article inspection process, which surfaces manufacturability issues a prototype run doesn't
Where estimates typically go wrong
The most common estimation failure isn't underestimating any single stage — it's assuming stages happen sequentially and without repetition, when in practice a design revision (triggered by a bring-up issue, a certification failure, or a DFM finding) resets the fab/assembly cycle and pushes everything after it. Budgeting for at least one full revision cycle as the expected case, not the worst case, produces a more realistic schedule than assuming the first board works.
Parallelizing what can be parallelized
Not everything has to be sequential. Firmware development can proceed against a development board or simulator while custom hardware is still in fabrication. Certification pre-compliance testing can happen on an early prototype rather than waiting for the final design. Enclosure tooling can start once the board's mechanical envelope is locked, even before every electrical detail is finalized. Identifying which stages can genuinely run in parallel, versus which ones have a hard dependency on a prior stage completing, is where real schedule compression comes from — not by cutting corners on any individual stage.
A rough mental model for scoping
Rather than a single number, a useful estimate breaks into ranges per stage with explicit assumptions stated (how many fab/assembly cycles assumed, whether certification is pre-compliance-tested early or left to the end, whether components are in stock or need lead time) — because the biggest driver of whether an estimate holds up isn't the accuracy of any single stage's duration, it's whether the assumptions behind the plan turn out to be true.
How we approach this
We scope hardware timelines against all of these stages explicitly, with assumptions stated clearly enough that a client can see exactly what would change the estimate. See our embedded hardware work for how this fits into a full hardware engagement.