Hardware Product Development Process Explained

Names of stages differ between organisations, and the name is not evidence. Each stage states the question it may answer, the build configuration, and the record you need before paying for the next one. Figures for the sensor below are hypothetical teaching assumptions: not supplier quotes, and not BrahmWorks test results.

Four lines should be disputable. Who uses it, and to do what? Which environment does it see? Which function is mandatory? Which constraints bind — cost at a stated volume, safety, certification — and what is out of scope?

For this hypothetical sensor the user is a facilities technician reading temperature on a dashboard, not an occupant pairing an app. It sits indoors on plasterboard, on a primary cell, with a 2.4 GHz access point that may be a room away. The function you cannot drop is a reading stream in which a gap is visible. Assume, for the exercise only, a first quantity of 500, no mains in the product, and no medical or life-safety claim. Any certification that does apply is a separate scope.

“Access point 8 m away, one plasterboard wall” can be tested. “Reliable connectivity” cannot. Change the wall, the distance or the user, and the criteria change with them.

Say which discipline owns which behaviour, and write the interfaces tightly enough that the other two can design to them.

Mechanical design owns the enclosure, the mount, the battery door and the air path. Electronics owns the radio, the sensor circuit, the supply and the board. Firmware owns join, retry, store-and-forward, the watchdog and the log. A keep-out is a CAD volume, not “keep metal clear”. The supply interface is a voltage range plus impedance during transmit. “Connected” means an application acknowledgement within a stated time, not an RSSI reading on a kit.

Price the radio choice before freezing the outline. These prices are invented.

INR 180 a unit is 500 × 180 = INR 90,000 on that first batch. It is saved only if the cheaper radio passes the packet test closed up, on the real cell. Until then the saving is unearned, and it is smaller than the tool figure used later. Write down the option you reject.

One question per build. That is prototype development, not a short production run.

Cosmetics, draft, bosses and the final resin may be faked; a printed shell is enough. A development module is fine when the question is firmware logic. Do not fake the decision you are about to fund. A radio decision needs the antenna, the cell and the plastic in place. An end-of-life decision must not use a stiff supply: it hides the sag when the radio transmits. Note every substitution, and note which conclusions it rules out.

The teaching criterion, invented for this sensor:

Enclosure closed. Cell at 3.0 V open-circuit (the assumed low point, not a datasheet limit). Unit on plasterboard, access point 8 m away past one similar wall. At least 95 of 100 readings acknowledged, 30 seconds apart, each acknowledgement within 2 seconds, three units. Linked but unacknowledged is a fail. RSSI is not the limit.

A real product takes distance, loss and timeout from its own service. Pasting these numbers elsewhere does not make that brief rigorous. Firmware must log the attempt and the acknowledgement or nobody can score the run. The 3.0 V point has to be the cell, or a source with a stated impedance, because the transmit pulse drops the rail below the open-circuit reading. A bench supply held at 3.0 V will pass a radio that brown-outs on the cell. Agree that threshold before calling the link reliable.

Order the second spin only when the frame is dated and owned; one radio is chosen and the other rejected in writing; keep-out, supply range, impedance, air path, programming header and “acknowledgement” are all specified; the first log separates results from fakes; the spin’s single question is whether this outline, cell and shell meet the packet criterion; and every open issue is either closed by this spin or explicitly deferred.

The cell may sit in the keep-out, and the only pass used a stiff supply. Spin now, while the shell is printed, or freeze the outline and cut a soft tool. Planning figures, not quotes:

• Eight bare boards: INR 14,000
• Assembly of changed parts: INR 22,000
• Three engineer-days at INR 9,000 a day internally: INR 27,000
• Spin total: 14,000 + 22,000 + 27,000 = INR 63,000, over 18 calendar days

Assume, as a judgement for the exercise and not as data, a 40 percent chance the closed unit fails on the real cell. Failure then costs INR 2,40,000 of tool work, another INR 63,000 spin, and 35 calendar days. Do not turn the days into money.

Expected cash if you skip: 0.4 × (2,40,000 + 63,000) = 0.4 × 3,03,000 = INR 1,21,200, or INR 58,200 more than paying INR 63,000 now. Expected delay if you skip: 0.4 × 35 = 14 days, which is less than the certain 18. Rupees say spin. Days say wait. Adding them needs a cost of delay you do not have; do not invent one.

The sums do not decide the design. Forty percent is not a measured rate and not a BrahmWorks result. INR 2,40,000 is not a quotation. Expected cost is the wrong tool for shock, fire or certification, which need their own evidence. Beating INR 1,21,200 does not mean the packet limit is met. Only the test does, and only on the setup written above. Nothing here transfers to another product.

Name which prototype features are temporary before the outline is treated as fixed.

Clips on unmarked test pads, and USB instead of the cell, taught the first board. Standoffs then landed on those pads. Moving the pads on the next spin is inside the INR 63,000. After tooling it is a tool change and a new board, and the clipped logs are void because that setup was not the product. Mark test access, keep-out and the cell on the outline first.

In the same review, walk the assembly order. Screws that trap the sensor flex, or a lid over the programming header, make the line test a different product. A sentence in the instructions will not fix a sequence that hides the thing you must reach. Printed shells and the real board are enough to see it. You are not approving a mould.

Run the packet test and the other written limits on a named revision. Keep unit identity, mechanical and board revisions, firmware version, the actual supply, the setup, the method, the limit and the result, plus the log. “Connectivity was good” is not a result. Leave a failure in the state that failed, then change the design, change the limit, or accept it under an owner. Two passes and a third unit you cannot explain are not a pass. If a logging fix also changes retry current, say which older passes still stand. This is design verification. A later end-of-line check only asks whether that unit was built correctly.

Once the criteria are met on a configuration you will repeat, the remaining question is whether someone else can build and test it from drawings, a BOM, firmware and instructions that name the same revision. That pilot and release package is How to Take a Hardware Prototype to Production. Opening a pilot while keep-out, cell and “acknowledged” are still undefined freezes a prototype.

BrahmWorks has worked on UltraFast EV charging hardware, where the enclosure, screen mounting, cable routing, component access and assembly sequence are reviewed together. Electrical safety and compliance are their own scope. Use the same split on a small sensor: do not sign off housing, electronics and test in separate meetings, and do not treat a demo as the safety case. No yield, cost, time or test result from that charging work is stated here.

Each item needs a file, a revision and an owner, or it stays open.

• User, environment and the mandatory function are written.
• Quantity, safety, certification and exclusions are on that page.
• Mechanical, electronics and firmware each have an owner.
• Interfaces are dimensions, pinouts or messages.
• The log says what was faked and what that forbids.
• The next spin has one question and a numeric limit, written before layout release.
• Antenna, sensor path and supply are where the test needs them.
• Programming and probe access survive assembly.
• The rejected architecture is recorded, with the reason.
• Each failure is a design change, a limit change, or an accepted gap with an owner.
• Safety and compliance have their own evidence.
• Every record names its revision.

As many as you have unanswered questions, one question per spin. Changing the shell, the antenna and the supply together gives a result you cannot attribute. Plan a learning build, then one honest build of the features the decision uses.

No. The log that defines an acknowledgement has to exist or the test cannot be scored, and that can start on the radio you already have. Treat firmware as unfinished while supply impedance, antenna position and the reset threshold are still moving.

When you can say which process you are heading for, and which prototype features are temporary. You do not need a finished model. You do need to know machining, moulding or sheet metal, and the quantity at which tooling would be rational. Start after the design is called finished and the manufacturable version becomes a new design; the old evidence does not follow it.

This article is the work before a prototype is worth producing: frame, interfaces, and an honest list of fakes. Prototype-to-production work starts from a build that already functions and asks whether another team can repeat it. Packaging that later step too early mostly freezes the prototype you happen to have.

Bring the frame, the interface notes, the list of fakes and the failure log. BrahmWorks can name the next stage from that evidence, and the one question the next build is allowed to answer. If the unit already works and the gap is repeatable build and test, the review is the handoff linked above.

Review the next stage with BrahmWorks