How Long Does It Take to Develop a Hardware Product?

Effort and calendar are different numbers. Person-days can be spent by several people in the same week. A date cannot. Extra people shorten only work that actually splits. They do not shorten a board already at the fabricator, a tool not yet released, or a test that needs the tooled part. Every duration below is a hypothetical teaching assumption. None of it is a BrahmWorks timeline, a quotation, or a plan to copy.

Decision time waits on a named person: architecture, resin, claim. Leaving the choice open does not keep later work moving. It queues it. A weekly status meeting that closes nothing spends this clock twice.

Design time is CAD, schematic, layout, and firmware you can write before the custom board exists. Some of it splits. One outline that one person must draw does not. A second designer waiting on that outline is another queue, not capacity.

Lead time starts when a supplier has a file they can build: bare boards, a tool, a custom cable, a cell with a real part number. Asking for a date before the file exists does not start the clock. It produces a date that will be renegotiated.

Loop time is a repeat you have not earned the right to delete: a second layout after bring-up, a tool change after a bad fit, a lab repeat after a relevant change. A plan with zero loops assumes the first answer is right. If you will not fund a loop, write that beside the date so a miss is a broken assumption, not a surprise.

What each stage is allowed to answer is set out in Hardware Product Development Process Explained. This article does not restate that gate. It asks how long the chain is once the open questions are known.

Overlap is real when the second task does not need the first task's result. A printed grip can be made while a schematic is open, if the grip is not the question you are funding. Protocol firmware can proceed on a development board during fabrication, if you accept that pinout and supply may still move, and if you do not file that firmware as evidence about the custom board.

Overlap is fiction when the second task consumes an answer you do not have. Releasing a tool while the outline still moves spends the lead time on the wrong geometry. The rework is a new lead time. Booking a compliance slot for a build you already expect to change does the same to a laboratory calendar. The sample has to be the product you mean to submit.

Mark each task with the artefact it needs in hand. Parallel is a property of the dependency, not a way of drawing the chart so a review looks shorter.

The teaching product is a mains-powered indoor display that reads a bought sensor and shows a number. The first build is a supervised trial, not a shop unit. It is not a BrahmWorks project.

Invented calendar days:

• Architecture of board and window: 10, starts now.
• Layout: 18, after architecture.
• Fabrication and assembly: 21, after layout release.
• Bring-up: 12, after boards exist.
• Enclosure CAD of the outline bring-up confirmed: 16.
• Printed fit: 8, needs that CAD and a real board.
• Tool: 40, after fit on the confirmed outline.
• Verification on tooled parts: 18, after the tool.

Display firmware on a development board is off this chain. If bring-up shows the real supply cannot support the update rate, the chain grows. Say that in the same note as the date.

Waiting path, enclosure CAD held until bring-up ends:

10 + 18 + 21 + 12 + 16 + 8 + 40 + 18.

10 + 18 = 28. 28 + 21 = 49. 49 + 12 = 61. 61 + 16 = 77. 77 + 8 = 85. 85 + 40 = 125. 125 + 18 = 143 calendar days.

Overlap path: start enclosure CAD when layout finishes, and still do not release the tool until a brought-up board has been fitted. Layout ends on day 28, so CAD ends on day 44. The board is not ready until day 61, so fit still runs from day 61 to day 69. Tool ends day 109. Verification ends day 127.

The saving is 143 − 127 = 16 days. That is the CAD duration, not the 33 days of fabrication and bring-up. Fit could not start before the board existed, so those 33 days stay on the path. You cannot harvest a lead time you are also waiting on.

Assume, as a judgement for the exercise and not as data, a 30 percent chance that bring-up moves a connector and the CAD is redrawn. If the tool was not released, the redraw starts at day 61 and the finish returns to day 143. Expected finish: 0.7 × 127 + 0.3 × 143 = 88.9 + 42.9 = 131.8 days. Expected saving versus waiting: 143 − 131.8 = 11.2 days. Expected extra design labour: 0.3 × 16 = 4.8 days. Do not turn 11.2 days into money. You do not have a cost of delay, and inventing one would pretend the sum decided a business fact it does not contain.

Release the 40-day tool at day 69, before that chance is resolved, and this sum no longer describes the programme. A wrong tool is a further lead time, not a 16-day redraw. The rational overlap here is CAD during fabrication. It is not the tool.

On the waiting path the design tasks are 10 + 18 + 16 = 44 days, and the calendar is 143. The other 99 days are suppliers, bring-up and verification. "Four engineer-months" has not said whether it means effort or the date. A second designer can attack the 44 days only where the work does not share one unfinished outline. They do not turn 143 into 99.

Replace every input. Nothing in the 143 days is a BrahmWorks duration. The method is the dependency list. The total does not travel to the next product.

• Every task names the artefact it needs before it starts.
• Supplier lead times start at file release, not at the kickoff.
• Loops you refuse to fund are written as assumptions.
• Overlap is marked only where the dependency allows it.
• Tool, laboratory slot and long custom parts are not released on an outline you still expect to move.
• The number you show externally is labelled as effort or as calendar.
• Firmware on a development board is not evidence about the custom board.
• One person who must approve architecture, resin and claims is visible as a queue.
• Safety and compliance evidence have a place on the path, not a footnote that says later.

Twelve weeks has no chain. It hides whether the tool, the board turn or an open decision sets the date. Teams then slip a plan that could never have landed, because one lead time alone was longer than the quote. If there is no path, there is no estimate.

Only firmware on the critical path. Protocol work on a development board can finish early and change nothing about the tool. Drivers that need the real supply and the real sensor cannot finish before that hardware exists.

Only when that turn is on the path and you do not expect to scrap it. A faster turn on a board you are about to respin buys days you will throw away. A saving that tempts an early tool release is not a saving.

When questions that would change the tool or the board are closed, and what remains is lead time, verification and a pilot of the configuration you will repeat. A production date on an open architecture is a day you do not control. The pilot's records are a later subject, not a fixed tail of "two weeks for manufacturing".

BrahmWorks has worked on UltraFast EV charging hardware, where the enclosure, the screen, the cable routing and the electronics are one assembly. A connector move is then both a layout change and an enclosure change. Review them together before either lead time is released. Electrical safety and compliance stay their own scope. No yield, cost, time or test result from that work is stated here.

Bring the dependency list, the lead times you hold in writing, and the loops you have not closed. BrahmWorks can say which link sets the date, and which overlap is CAD that will be drawn twice.

Review the next stage with BrahmWorks