From Prototype to Production

A working Prototype doesn’t mean you’re ready for Production.

Getting the first prototype working is an exciting moment. The electronics turn on, the mechanical parts fit together and the product does what it is supposed to do. Maybe you have already shown it to customers, investors or other people in the company. At that point, it is easy to feel like you are getting close to manufacturing.

But something I have seen working around hardware projects is that this can also create a false sense of how close you really are. A prototype proves that you can make something work. It doesn’t prove that you can manufacture it repeatedly, at the right quality, at the right cost and on the timeline you planned.

That transition is where a lot of the challenges in hardware development really start. A team can spend months getting to its first functional prototype and still have a lot of work ahead once DFM starts and the product moves through EVT, DVT and PVT.

The product doesn’t necessarily fail. More often, the timeline starts moving.

A Prototype proves possibility, Not Production

After a successful prototype, the path forward can look pretty simple:

Prototype → finalize the design → manufacture → launch.

In reality, it is rarely that clean. Once you start thinking about manufacturing, new constraints appear that weren’t necessarily important when you were building only a few prototypes.

A component may need to move, which means the enclosure needs to change, which can then affect tooling. A supplier may tell you that a tolerance is difficult to maintain consistently. A test can expose a weakness that didn’t appear in the first prototypes. A component that was easy to buy for ten units may suddenly have a very different lead time when you need thousands.

The same thing happens with assembly. Something that works perfectly when an engineer is building one device by hand may be too slow, too complicated or simply unreliable on a production line.

None of this means the original engineering was bad. You’re just starting to answer a different question. Instead of asking “Can we make this work?”, you’re now asking “Can we make this work consistently, repeatedly, at the right cost and at scale?”

That second question is a lot harder.

DFM is where a lot of assumptions get tested

Design for Manufacturing can sometimes be treated as something that happens once the design is almost finished. From what I have seen, this is actually where you start discovering how many decisions that worked for the prototype don’t necessarily work for production.

When you’re only building a few units, you have flexibility. An engineer can work around an awkward assembly, manually adjust something, accept an unusual tolerance or use an expensive component because you only need five or ten of them. Once you start talking about hundreds or thousands of units, those small workarounds become much bigger problems.

Now you need to know whether components can be sourced at the volume you need, whether the tolerances actually make sense for the manufacturing process, whether the product can be assembled and tested efficiently, and whether variations in manufacturing will affect performance. You also need to know if your suppliers can meet the expected lead times and if all of this still works with your target cost.

Every time one of those answers isn’t what you expected, you may need another engineering iteration. This is where the original schedule can start getting challenged.

EVT, DVT and PVT are Learning Loops

Most hardware projects go through some version of EVT, DVT and PVT.

EVT — Engineering Validation Test is where the team proves that the engineering implementation works and identifies technical problems that still need to be solved.

DVT — Design Validation Test comes when the design is getting closer to its final configuration. The focus moves toward validating that the product meets its specifications and works under the conditions it was designed for.

PVT — Production Validation Test is where the focus moves toward the manufacturing process and proving that the product can actually be built the way you intend to build it.

On a project plan, this looks very clean:

EVT → DVT → PVT → Production

In reality, each phase has its own feedback loop. You build something, test it, learn from it, make changes and build again. Sometimes you do that once. Sometimes you do it several times.

I think this is one of the easiest things to underestimate when building a hardware development schedule. You can’t perfectly predict how many iterations you’re going to need because the whole point of validation is to find problems you don’t know about yet. That uncertainty needs to exist somewhere in the schedule.

Trying to save time can end up costing more time

The difficult part is that every iteration has a cost. Another prototype build costs money, another redesign takes engineering resources, mechanical changes can require new parts or tooling, and new components can bring new lead times.

There is also the pressure of the launch date. When everyone wants to move faster, another EVT iteration can look like a delay. It can be tempting to move forward and deal with the remaining issues during DVT.

The problem is that moving to DVT doesn’t make an unresolved EVT problem disappear. Now DVT is doing two jobs at the same time: validating the design while the team is still solving engineering problems that should ideally have been closed earlier.

If those problems move again into PVT, changes become even more difficult. Parts may already have been ordered, tooling may already exist, suppliers may have reserved production capacity and testing may have been built around the previous design. A change that was relatively easy during EVT can suddenly become expensive and take much longer.

This is one of the things I find interesting about hardware development: trying to remove an iteration to save time can sometimes be exactly what makes the project late.

That doesn’t mean adding iterations just for the sake of it. It means accepting that sometimes another build is exactly what you need before moving forward.

Four hours of engineering can mean three weeks of waiting

Another thing that is easy to underestimate is the difference between engineering time and actual iteration time.

Let’s say a mechanical engineer identifies a problem and changes a part. The CAD modification itself might only take four hours, but that doesn’t mean you have the answer four hours later.

The supplier needs to receive and review the new drawing, quote the change, source the material and fit the part into its production schedule. The part then needs to be manufactured, shipped, assembled into the new prototype and tested. Only after all of that do you actually know if the change solved the problem.

The engineering change took four hours. The iteration might have taken three weeks.

When manufacturing is happening in another country, logistics can make that loop even longer. Now multiply the same process across mechanical, electrical, firmware, acoustics, suppliers and manufacturing, and you can see how quickly a development schedule starts moving.

This is why I don’t really see lead time as just a purchasing problem. In hardware, it is part of the development process.

Time-to-market is usually lost little by little

Hardware projects don’t always become three months late because one huge thing went wrong. A lot of the time, the delay happens in small pieces.

An EVT build takes longer than expected. A supplier needs another week. A test finds a problem. A new component has a longer lead time. A mechanical change requires another set of parts. DVT starts before everything from EVT is completely closed, and another validation build becomes necessary.

None of those things individually looks terrible. Together, they can move the launch by weeks or months. By the time the delay becomes obvious, a lot of the flexibility in the schedule may already be gone.

That’s why I’ve started thinking about time-to-market a little differently. It’s obviously important to move quickly, but simply asking every development phase to happen faster doesn’t necessarily protect the launch date.

Sometimes the better question is: what are we carrying into the next phase that we should have solved already?

What I take from this

I don’t think the answer is to make hardware development slower. Speed matters, cost matters and market windows matter. But uncertainty is part of developing something new, and pretending it isn’t there doesn’t make it disappear.

For me, that means leaving some room for iteration instead of automatically seeing another build as a failure of the schedule. It means bringing manufacturing partners into the conversation early enough that their feedback can still influence the design, and understanding supplier lead times before they become critical. It also means being careful about moving from EVT to DVT, or DVT to PVT, just because that’s what the original calendar says should happen.

And finding a problem early isn’t necessarily bad news. A problem found during EVT can be frustrating, but that same problem found during PVT can be expensive. If you only discover it after production has started, it can be much worse.

The goal isn’t to build a product without ever finding problems. It’s to create a development process where you find those problems while they are still relatively easy to fix.

One last thought

The first working prototype is exciting because you finally have something tangible. You can hold it, turn it on, demonstrate it and show it to a customer. After months of development, it finally feels like a real product.

Manufacturing readiness is a lot less visible. It’s in drawings, tolerances, test results, supplier conversations, build reports, tooling decisions, component availability and a lot of small engineering decisions that most people will never see. But that less visible work is what turns a working prototype into something you can actually sell at scale.

So once that first prototype works, I don’t think the next question should immediately be:

“How quickly can we manufacture this?”

I think a better question is:

“What do we still need to learn before we can manufacture this reliably?”

It sounds like the slower question, but in hardware, it can sometimes be the one that gets you to market faster.