What a Prototype Needs Before Engineering Starts

A prototype that arrives at engineering with a clean CAD model, a tidy pitch deck, and a folder of inspiration screenshots is not ready. It is a drawing of an intention. What engineering needs is something rougher and far more useful: evidence that the thing has been held, dropped, argued over, and rebuilt at least once by someone who is not in love with it.

Most hardware teams learn this the expensive way. They hand over a beautiful model, engineering spends three weeks turning it into something manufacturable, and the first machined sample reveals that a cable cannot be routed, a screw cannot be reached, or the whole assembly weighs almost twice what the business case assumed. The design was never wrong in the abstract. It was wrong in the hand.

The two questions a prototype must already answer

Before a single engineering hour is booked, the prototype should be able to answer two questions with a straight face. First: does this solve the problem in a way a real person will actually use? Second: is there a plausible path to make it at a cost and volume the business can live with?

Neither answer needs to be final. Both need to be backed by something a person can point at. A video of a test user fumbling the latch. A bill of materials that has been priced, even roughly. A sketch showing where the battery sits and how it gets out. If those artifacts do not exist, engineering is not receiving a prototype. It is receiving a wish.

Lo-fi beats hi-fi at the handoff

There is a strong pull toward making the handoff prototype look professional. Foam board gets replaced with machined aluminum. Hot glue becomes epoxy. The model starts to feel like a product, and everyone relaxes.

That relaxation is the danger. A polished prototype invites engineering to treat decisions as settled. A crude one invites questions, and questions are the whole point of a handoff. A taped-together test rig with a visible battery holder and a hand-labeled switch tells the truth: this is a hypothesis, and the job is to stress it.

Rough prototypes also fail faster. A cardboard enclosure can be cut and retaped in an afternoon. A machined one takes a week and a purchase order. The team that can iterate five times before engineering gets involved will hand over a far better-posed problem than the team that iterated once, beautifully.

What a bill of materials must contain at this stage

Full costed BOMs are an engineering deliverable. What the prototype phase owes is a short list with three columns: part, rough cost at the target volume, and source. The source column matters most. A part with no source is a part with unknown lead time, unknown minimum order, and unknown risk of disappearing next quarter.

The list should flag every component that is single-source, custom, or long-lead. Those three categories are where schedules die. A prototype that quietly depends on one overseas supplier for a bespoke sensor has not de-risked anything; it has moved the risk downstream where it is more expensive to fix.

Cost estimates can be rough. They cannot be absent. Engineering needs a target to design against, even a loose one, because every material and process decision downstream is a trade against that number.

The user evidence problem

Founders and product leads tend to arrive with enthusiasm and anecdotes. Engineering tends to arrive with skepticism and tolerances. The prototype is where those two climates have to meet, and the meeting goes badly when the evidence is thin.

What helps is not a survey with two hundred responses. It is five to ten sessions where a real person used the thing while someone watched, took notes, and did not intervene. The notes should record where hands hesitated, where instructions were ignored, where the device got set down and not picked back up. Those moments are the design brief.

Engineering cannot do this work later. Once tooling is in play, user friction becomes a change order. The prototype phase is the last cheap moment to discover that the primary button is in the wrong place.

Tolerances, interfaces, and the parts nobody owns

A surprising share of handoff delays come from interfaces nobody thought to define. Where exactly does the PCB mount? What is the gap between the button cap and the housing? Which part owns the datum for the whole assembly?

The prototype does not need final tolerances. It does need a named owner for each interface and a rough sense of how tight things must be. A button that rattles by two millimeters in the prototype will rattle in production unless someone decides, early, that it should not.

This is unglamorous work, and it is exactly the work that separates a handoff from a hope. Engineering can only design to interfaces that have been stated. Silence at this stage becomes assumption at the next.

A named failure mode beats a feature list

Feature lists are easy to write and hard to act on. Engineering needs something sharper: a short list of the ways this product could fail, ranked by how much it would hurt. The latch that could pop open in a bag. The seal that could degrade after a hundred cycles. The radio that could drop out in a pocket.

Each named failure mode should come with the cheapest test the team already ran, and what happened. Even a bad result is useful. A prototype that admits the seal leaks after fifty cycles is worth more than one that has never been cycled at all, because the first gives engineering a target and the second gives it a mystery.

Regulatory and safety questions do not wait for tooling

Depending on the product category, there are questions that must be answered before engineering commits: which standards apply, whether a battery chemistry is restricted in a target market, whether the enclosure needs a specific flame rating. These are not details to sort out later. They change materials, geometry, and cost.

A prototype does not need certifications. It needs a clear-eyed list of the regulations in scope and a named person responsible for each. The worst outcome is discovering, three months into engineering, that the chosen plastic cannot be used in the largest market.

The prototype nobody wants to hand over

The best handoff prototype is usually the one the team is slightly embarrassed by. It has tape on it. It has a part that was 3D printed overnight because the real one had not arrived. It has a spreadsheet attached with more questions than answers.

That embarrassment is a feature. It signals that the prototype was used hard enough to break, questioned enough to be revised, and honest enough to admit what it does not know. Engineering can work with that. What it cannot work with is a model that looks finished and answers nothing.

A prototype is ready for engineering when the team can point to the moment it failed in a user's hands, name the part that is hardest to source, and sketch the interface between the two subassemblies without arguing about it. Until then, the drawing is not a brief. It is a mood board with a battery.