If you’re planning a launch around a physical product, the schedule is the thing that will keep you up at night. Software slips can usually be absorbed by shipping less. Hardware slips can’t, because a board that isn’t finished can’t be fabricated, and a factory slot you miss is a slot somebody else takes.
The honest answer to “how long does this take” is that it depends on the product, which isn’t a useful answer to plan against. What is useful is knowing which phases consume the calendar, which are elastic, and which are governed by other people’s schedules rather than yours.
This guide walks through how a hardware program actually spends its time, so you can build a launch plan with decision points in it rather than a single date you defend until the week it fails.
Understand What Each Phase Contributes
Our hardware design practice runs a program through six stages, and each one contributes something different to the calendar. Knowing what each is for tells you where a week saved is real and where it’s borrowed.
- Requirements and Scoping. Establish what the product must do, the conditions it has to do it in, and the cost of being wrong about each requirement. This is the cheapest week in the program and the one most often skipped. Every unwritten requirement becomes a design change later, at a point where changes cost fabrication runs instead of conversations.
- Architecture and Component Selection. Block diagram, power budget, and a bill of materials checked against live distributor stock and lead times. Second sources get identified here for anything single-sourced. This is also where you find out that the part you designed around has a twenty-six week lead time, which is far better news now than in four months.
- Risk Reduction and Breadboard. Build the least certain subsystems on their own and prove them. We’ve found this is the highest-leverage stage in the whole program. An unknown resolved on a breadboard costs a few days. The same unknown resolved after layout costs a spin.
- Layout and First Article. Schematic capture, PCB layout, design review, fabrication, and assembly. The layout is engineering time you control. The fabrication turnaround is somebody else’s queue, and the first point in the program where waiting becomes a line item.
- Bring-Up and Validation. Firmware against production silicon, measured against the error budget agreed at scoping. This is where the surprises live, and where the second design iteration gets defined.
- Transfer to Manufacture. Production documentation, a functional test fixture, and a supervised handover where the receiving team builds a unit. Treated as scope, this is predictable. Treated as a remainder, it’s the phase that eats the month before launch.
A full development engagement across all six is typically four to nine months of work. Where a specific product lands in that range is set by the number of unknowns at the start, not by the number of features at the end.
A Working Prototype Is Not Most of the Way There
This is the single most common planning error we see, and it’s an understandable one. A prototype on the bench does the thing. It’s visible, it’s demonstrable, it convinces a board, and it feels like the finish line is close.
A working prototype establishes that the concept is viable. It doesn’t establish that the design can be built repeatably, sourced reliably, or maintained in the field. The distance between those two states accounts for most of the schedule and most of the cost.
Consider what changes between the two. Thermal and mechanical behavior shifts once the electronics move into a sealed enclosure. Component availability moves between design and production. Test procedures that live in one engineer’s head can’t be handed to a contract manufacturer. None of that is visible on a breadboard, and all of it has to be resolved before a factory can build the thing without a phone call. Treat the demo as the point where the production engineering starts, not as the eighty percent mark.
Plan for Two Design Iterations, Not One
Two design iterations is a realistic expectation for a product of moderate complexity. We say that out loud during scoping because the alternative is a plan that only works if nothing surprising happens on a first article, and something surprising always happens on a first article.
The first spin proves the architecture and finds the problems. The second spin fixes them and is the one you validate against. A program that budgets for one spin doesn’t get fewer spins, it gets the same number with an unplanned gap in the middle of the launch calendar and an uncomfortable conversation attached.
There’s a related trap in the other direction. If a program is heading toward a fourth and fifth spin, the cause is almost never bad layout. It’s that the requirements were still moving after the design started. That’s why the scoping week earns its place, and why we’d rather spend a fixed-fee week arguing about requirements than a fabrication run discovering them.
What Quietly Extends a Schedule
The delays that hurt are rarely the ones in the project plan. They’re the ones that live in other organizations’ calendars.
- Component lead time. A bill of materials validated against live stock during design is not the same as a bill of materials that can be bought in quantity six months later. Long-lead parts should be identified in the first fortnight and ordered well before you need them. We flag single-sourced components with named alternatives and the layout accommodations those alternatives would require, which turns a supply interruption into a substitution rather than a redesign. Our post on scoping a connected product covers where sourcing decisions belong in the wider system.
- Certification and compliance. Formal emissions and safety testing happens at an accredited laboratory, on that laboratory’s schedule, and a failed test means remediation plus a return visit. Designing against the requirements from the outset and taking pre-compliance measurements during development is what keeps this to one visit. Booking a chamber after the design is frozen is how a program loses a quarter.
- Enclosure tooling. Printed and machined parts are fast. Injection molding is not. Tool fabrication, first shots, and tool modification form their own schedule that runs alongside the electronics, and the decision about which production method you’re using needs to be made early enough for that schedule to fit inside your launch date rather than after it.
- Requirements that arrive late. A new market, a new certification region, a new integration promised to a customer. Each is legitimate and each costs a spin if it lands after layout. This is worth a standing question at every milestone review.
What Genuinely Compresses One
Some compression is real, and it’s worth knowing which.
- Parallelize firmware and layout. Firmware development against development hardware can run while the board is in fabrication, so bring-up starts with working code rather than a blank repository.
- Order long-lead parts against the architecture, not the layout. Once the architecture is settled, the expensive and scarce parts are known. Buying them then, rather than at first-article assembly, removes weeks of dead time.
- Run pre-compliance early. Measuring emissions on a first article tells you about a problem while there’s still a planned spin to fix it in.
- Keep the disciplines under one team. A large share of hardware delay is handoff: electrical waiting on mechanical, firmware waiting on a decision neither owns. We hold all three in-house because the transitions are where risk concentrates, with no partner network and no offshore bench, so a program doesn’t change hands part way through.
What doesn’t compress a schedule: cutting risk reduction, design for manufacture, or the test fixture. Those move the delay past your launch date, where it costs more and is visible to customers.
Build a Schedule With Decision Points in It
The most useful thing you can do with all of this is to stop planning toward a single date and start planning toward a sequence of decisions.
We structure development engagements around milestones with a defined decision point at each one, and you should structure your internal plan the same way. At each milestone you should be able to answer three questions: what did we learn, does the plan still hold, and what would we do if it doesn’t.
- After scoping. You have a ranked risk list and a cost attached to being wrong about each item. This is the cheapest place to change your mind about scope, and the last place where changing it is free.
- After architecture. You have real lead times and real costs. If the launch window and the component reality disagree, they disagree here, in writing, while both are still adjustable.
- After first article. You know what the second spin has to fix. This is where a launch date becomes a forecast instead of a hope.
- After validation. You know whether you’re transferring to manufacture or spinning again. Tooling, certification, and inventory all key off this one.
Building the plan this way also changes what a delay means. A milestone that moves is information you get early, with options attached. A single date that moves is a crisis with none.
Planning a Launch You Can Actually Defend
A hardware schedule you can defend to a board is one that names its unknowns and says what it will do about each. That survives contact with reality considerably better than a Gantt chart with a date on the right-hand edge.
If you’re building the plan now, the highest-value work available to you is the week that turns your requirements into a ranked risk list. It’s also the smallest engagement we offer, a fixed-fee review or scoping week concluding in a document you own and can execute with any competent team. Before you commission it, read our guide to the questions to ask a development partner, because the answers tell you a great deal about whose schedule you’ll be working to.
Our coastal water quality monitoring case study shows how phases and iterations played out on a real program, where a partial node went in the water months before the design was finished and settled more of the outcome than the bench work did. To talk through your own calendar, our process page sets out how an engagement is sequenced and what each stage commits to.