A Prototype Is Not a Product: Crossing to Manufacturing

What this is. Opinion + Experience + Fact (30% opinion · 40% experience · 30% fact). Written in collaboration with AI — I discuss, I do not outsource.

Why a working prototype is nowhere near a shippable product, and how the factory-side disciplines — design-for-manufacture, staged builds, factory test — decide whether a good idea ever reaches volume. The short version: a prototype answers "can it work?"; manufacturing answers "can we build a thousand that all work, on time, at a price that makes sense?" Those are different questions, and we help teams answer the second one.

There's a dangerous moment in every hardware project: the prototype works. It powers on, it does the thing, and it feels like the finish line. It isn't. A prototype is a proof of concept — an answer to "can this work at all?" A product is something else entirely: a design a factory can build repeatedly, at volume, on schedule, at a cost that leaves a margin, and that keeps working in the field for years. The distance between those two is where a lot of promising hardware quietly dies, and it's the distance we spend our time on at Ritzy Lab.

This is FactoryOpsLab — the manufacturing-side half of building a physical product. Let me lay out why the gap is real, why manufacturability is a design decision rather than a later step, and why the cheapest way across is people who have made the crossing before.

---

1. A prototype proves the idea; a factory proves the business

A prototype and a production run answer different questions. The prototype asks whether the concept is sound. The factory asks whether you can make many of them — identical, reliable, affordable, on time. "It works on the bench" is a hypothesis about one hand-built unit in ideal conditions. "A line can build ten thousand that all work, and they last in the field" is a claim you have to earn, and it's the one that determines whether the product becomes a business.

The trap is treating the prototype as most of the work and manufacturing as a formality at the end. In practice it's the reverse: the prototype is often the easy part, and the second question — build, test, cost, yield, reliability — is where the hard, expensive surprises live. (It's the same crossing as going from a working prototype to a factory building 10,000.)

▸ First principle. The prototype is the hypothesis; the production line is the proof.

2. Manufacturability is designed in, not bolted on

The reason manufacturing surprises are so costly is that they're really design problems discovered late. Whether a product can be built at volume is decided by choices made months earlier: design-for-manufacture and design-for-test (so the thing can actually be assembled and tested on a line), the staged build campaign — engineering, design, and production validation (EVT, DVT, PVT) — that catches problems while they're still cheap, the factory test systems that prove each unit, and the choice and management of a contract manufacturer.

The economics are brutal and simple: a constraint you catch early in design — whether it's a circuit board, an enclosure, or a moving part — is a small change; the same constraint caught after tooling is a respin, with the schedule and cost that implies. Every week you delay finding a manufacturing problem multiplies what it costs to fix. That's why manufacturability has to be a design input from the start, not an audit at the end.

▸ First principle. The cost of a manufacturing surprise grows with how late you find it.

3. Get factory-floor experience in the room early

The most reliable way to avoid a late surprise is to have someone in the room who has already met it — before the decisions are locked. That's what FactoryOpsLab does: we bring people who have taken products to volume into the design phase, while the choices are still cheap to change. Design-for-manufacture and design-for-test, the EVT-to-DVT-to-PVT progression, factory test, contract-manufacturer selection and management — the parts of a hardware program that don't show up in a demo but decide whether it ships.

Over 20+ years and 45+ products taken from idea to production line, the same lessons recur, and most of them are the kind that cost a respin the first time you learn them. Having that experience shaping your design early is the difference between finding a constraint on a whiteboard and finding it after you've paid for tooling.

▸ First principle. The fastest path to a manufacturable product is people who have manufactured one before.

Sources

The disciplines referenced here — design-for-manufacture (DFM), design-for-test (DFT), the EVT/DVT/PVT validation-build progression, factory test, and contract manufacturing — are standard hardware-product-development practice. This piece is method and lived experience; the only figures are our own track record ("20+ years," "45+ products"), and "ten thousand" is used illustratively for volume, not as a specific claim.

FAQ

Why isn't a working prototype the same as a product?
A prototype answers "can it work?" — usually for one hand-built unit in ideal conditions. A product must be buildable at volume: identical units, reliable, affordable, on schedule, and durable in the field. The distance between the two is manufacturing, and it's where most late, expensive surprises live.

What is design-for-manufacture (DFM) and why does it matter?
DFM (and its sibling, design-for-test, DFT) means designing the product so it can actually be assembled and tested on a production line, cost-effectively and repeatably. It matters because manufacturability is decided during design — a constraint caught early is a small change; the same constraint caught after tooling is a costly respin.

What are EVT, DVT, and PVT?
They're staged validation builds: Engineering Validation Test (does the design work?), Design Validation Test (does it meet all requirements reliably?), and Production Validation Test (can the factory build it at volume, at quality?). Running them in order catches problems while they're still cheap to fix.

When should manufacturing expertise get involved in a hardware project?
As early as possible — during design, not after. Bringing factory-floor experience in while the decisions are still cheap to change lets you catch manufacturing constraints on a whiteboard instead of after tooling, which is exactly what FactoryOpsLab is for.

This is a Ritzy Lab field note. If you've got a working prototype and a factory in your future, the longer story and how we work live on my profile. — Ritesh | ritzylab.com