Ask an engineer how long it takes to develop an electronic product and you get a shrug. Ask a founder and you get nine months, which is usually wrong by a factor of two. The honest answer for a connected device with custom electronics, an enclosure, firmware, and certification is twelve to twenty-four months from written specification to sellable inventory. Simple devices come in under a year; anything with a radio, a display, an app, a battery, and a mold is at the top of the range or beyond. Here is where the time actually goes.
The phase-by-phase schedule
| Phase | Typical duration | What it produces |
|---|---|---|
| Requirements and product definition | 3 to 8 weeks | Written spec, use cases, cost target, certification plan |
| Architecture and component selection | 2 to 5 weeks | Block diagram, processor and radio choice, power budget, preliminary bill of materials |
| Schematic capture and PCB layout | 4 to 10 weeks | Reviewed schematic, routed board, fabrication package |
| Fabrication and assembly of first boards | 2 to 4 weeks | Five to ten prototype units |
| Bring-up and hardware debug | 3 to 8 weeks | Working board, rework list, errata |
| Firmware development | 12 to 30 weeks, largely in parallel | Feature-complete firmware, drivers, production test hooks |
| Mechanical design and first tooling-quality parts | 8 to 16 weeks, in parallel | Enclosure that fits the board and the certification requirements |
| Second and third board revisions | 6 to 14 weeks total | Design that meets spec, EMC, and cost |
| Pre-compliance and formal certification | 6 to 14 weeks | FCC authorization, safety marks, test reports |
| DFM, production test development, pilot build | 6 to 12 weeks | Test fixture, work instructions, yield data |
| Production ramp | 6 to 12 weeks | First sellable inventory |
The durations overlap heavily, which is why the total is not the sum. Firmware runs alongside the second and third board spins, mechanical design starts once the board outline is stable, and certification planning begins at architecture. A schedule that runs these phases strictly in series is twice as long as it needs to be; one that assumes perfect parallelism is fiction, because most parallel work depends on hardware that does not exist yet.
Definition takes longer than anyone plans, and it should
The requirements phase looks like the easy part to compress and it is the worst place to try. Every ambiguity in the spec becomes an engineering decision made by someone without the commercial context, and each turns into rework later. The items that cause the most damage when left vague are target cost, battery life, operating environment, target markets, and whether there is an app.
Certification strategy belongs here too. A pre-certified radio module versus a chip-down radio design changes the schedule by two to three months and the unit cost by several dollars, and it cannot be deferred past architecture. The same applies to processor choice, covered in our guide to choosing a microcontroller for your product, because a mature software ecosystem can save a firmware quarter.
Plan for three board revisions
Experienced teams budget three PCB spins for a new design of moderate complexity. The first proves the architecture and always has mistakes. The second fixes them and typically fails pre-compliance or misses a power or thermal target. The third is the one you build. Four or more usually signals a specification that kept moving.
Each spin has an unavoidable cycle time: about a week for layout changes, one to two weeks for fabrication and assembly at prototype quantities, and two to six weeks of bring-up and test. Our breakdown of PCB prototype cost covers what expedited fabrication buys. A five-day turn saves a week; it does not save the debugging.
The way to reduce spins is not to rush layout. Run a genuine design review before release, prototype risky subsystems on small separate boards, and populate the first board with test points, jumpers, and current-sense resistors so debugging does not require cutting traces. Our article on EVT, DVT and PVT build stages explains what each build must prove.
Firmware is usually the critical path
Hardware schedules are visible because they involve purchase orders and shipping dates. Firmware schedules are invisible until they slip. On most connected products firmware is the largest single engineering effort and the last thing finished, particularly with a wireless stack, over-the-air updates, power management, and an app protocol.
Two things reliably compress it. Start on a development kit while the custom board is being designed, so drivers and application logic exist before hardware arrives. And treat production test firmware as a deliverable from the beginning rather than a scramble before the pilot build. Our guide to firmware development cost covers how effort scales with feature set.
The delays that actually happen
- Component lead times. A processor or power management IC on a long allocation can add months, and it is the one delay no amount of engineering effort fixes. Check availability during architecture, not at purchasing, and design in an alternate where you can. Our article on component end-of-life and availability covers the mitigation options.
- Certification failure. A first-pass EMC failure costs two to six weeks: diagnose, fix, respin if needed, re-book the lab. Pre-compliance screening before the design freeze is the standard insurance, as described in our guide to FCC certification for electronic products.
- Tooling. If the enclosure is injection molded, mold build plus first shots plus revisions is a ten to sixteen week block that must start before the design is truly final, which is uncomfortable and unavoidable.
- Late DFM feedback. A contract manufacturer reviewing the design for the first time at the pilot build will find things, and fixing them then costs far more than fixing them at layout. Bring the CM in during the second spin, as we argue in our guide to DFM for electronics.
- Scope change. By a wide margin the most common cause of an overrun. Every added feature after architecture costs more than it would have cost at the start.
What compressing the schedule really costs
You can pull a timeline in by roughly a quarter without breaking anything: expedite fabrication, run mechanical and electrical work fully in parallel, book lab slots speculatively, staff firmware more heavily. Beyond that, compression buys risk rather than time, and the failures show up after launch as field returns. For the wider picture, see our overview of how long product development takes.
Projects House builds electronic products end to end, from specification and architecture through board design, firmware, certification, and production handoff, with a schedule that names the risks up front. Tell us what you are building through our contact form.