0️⃣ Zero to Many Dilemma
Moving fast --> Scale
🦸 Guest Writer: David
David graduated from MIT in Mechanical Engineering and Physics. He ran a product development firm for seven years, primarily developing IoT devices across a range of industries. He also served as a researcher at the Plasma Science and Fusion Center and as Director of Hardware at Kepler51. He’s now working on oroForge, a lightweight PLM built for startups and SMBs, with the goal of automating the tedious operational tasks of engineering so hardware startups can scale faster and with fewer mistakes.
⚙️ Mechanical Engineering Resources:
We have put a dozen guides for mechanical engineering students and early professionals on our website
50 Hardware Startups who have raised less than $50 million (perfect internship targets)
How to handle The Behavioral Interview
What it take to be The 10X Intern
The zero-to-many dilemma that hardware companies face
Zero to one. One to many. Everyone in startups can recite the phrases. In software, the second one is mostly a question of money and infrastructure: spin up more servers, hire more engineers, ship faster, eventually get a DevOps guy. In hardware, one to many is a different beast, and most founders don’t see it coming until they’re already bleeding.
This is not an article about capital. Yes, injection molds cost money. Yes, a production run requires cash you probably don’t have yet. That’s real, but it’s the obvious problem, and the obvious problem is rarely the one that kills you. The problem I want to talk about is operational and organizational, and it’s sitting inside your team right now whether you know it or not.
The transition from zero-to-one and one-to-many is hard because the work changes, the people who thrive in it change, and the discipline required changes. All three at once. That’s the whole article.
Where Zero to One Actually Ends
Zero to one does not end when your first prototype works. It doesn’t even end when customers say they like it. It ends at DVT, assuming you’ve met your customer requirements. EVT tells you the product works. DVT tells you it works for the people who are going to buy it. Those are different questions, and answering the second one takes longer than most founders budget for.
One to many is PVT. You’re no longer asking whether the product works. You’re figuring out how to manufacture it reliably at scale: teaching your contract manufacturer how to build it, managing suppliers, writing test requirements, running the supply chain week over week.
Those are not the same problems. And they do not reward the same skill set.
Simple Guide of the EVT, DVT, and PVT process
Death by a Thousand Paper Cuts
A colleague of mine described PVT better than I ever have: death by a thousand paper cuts.
When you cross into production, the task count explodes, and almost none of it is what you’d traditionally call engineering. You’re emailing your CM. You’re chasing your vendor. You’re scheduling with a certification lab (underestimate how long this will take at your own risk). You’re purchasing parts, pulling price estimates for your exec team, documenting features for the next launch. The list does not stop. Each task is small. Collectively they bury you.
I felt this most acutely at a previous company, where I was the main hardware guy. The work I was good at, the work that got us to a product, quietly stopped being the work that needed doing. None of it was hard in isolation. There was just an endless amount of it, and it was all operational.
That’s the part nobody warns you about. The difficulty of one to many isn’t intellectual. It’s logistical and relentless.
The Engineers Who Build Fast Are Not the Engineers Who Scale
The people who excel at EVT and DVT are tinkerers. That’s not a knock. Scraping a prototype together, moving fast, iterating, that is a genuine gift and it can be fun and engaging. But it is not the skill set PVT demands.
PVT is documentation-heavy. It’s managing the CM, managing suppliers, maintaining supply chain visibility, defining test requirements. It’s engineering operations. As a tinkerer myself, I’ll be honest: that work doesn’t excite me. For other engineers it’s their bread and butter. That’s the point. It’s not a question of competence; it’s a question of interest and specialty.
So when you’re hiring, there’s a question worth asking every engineer: do you see yourself staying on the technical path as a senior engineer, or moving toward engineering management? The engineering-manager profile, broadly, is the one that thrives in PVT. The senior engineer is usually the one who got you through EVT and DVT.
Here’s the catch: you need the tinkerer first. You can’t skip them. So most startups hire that engineer out of necessity, which is correct. The savvy founder hires the tinkerer knowing they’ll need a different engineer at PVT, and plans for it instead of being surprised by it.
Jiga
Source custom parts with direct access to the manufacturers making them. No middleman, no black box. Jiga gives you a vetted network and one accountable partner standing behind every order. You know who’s building your parts and communicate with them directly. AI-assisted operations handle supplier matching, quoting, quality verification, and production tracking, so the relationships stay human while the operations run at speed.
A Connector, a Turnkey CM, and a Lost Month
Here’s the kind of paper cut that draws blood.
We were in production with a turnkey CM handling all the purchasing. One of our parts was a specialized connector. Instead of sourcing it from the original vendor, the CM quietly bought it through Digikey. Convenient, until the Digikey stock dropped out. Now they had to go engage the vendor directly, mid-production, from a cold start. That added a month to our timeline.
The lesson wasn’t that the CM made a bad call, though they did. The lesson was that I should have ensured they were communicating with the vendor directly on a critical part from the beginning. That’s a PVT discipline. It has nothing to do with whether the product works and everything to do with whether you can keep building it.
While we’re here: most people forget about testing at the CM entirely. Defining the tests your CM runs to validate the product, often building a test rig to do it, is real PVT work that doesn’t exist in the zero-to-one world. If you haven’t thought about how your CM proves each unit is good, you’re not done.
The Wrong File
The most expensive paper cut I’ve experienced was also the simplest.
We were getting molds made for an enclosure. At some point we added alignment pins so the two halves of the case would seat cleanly during assembly. An engineer had two versions of the file sitting on his desktop. He sent the wrong one. The one without the pins.
It cost about two to three thousand dollars to retool. We got lucky: the CM could machine the pins into the existing mold rather than recut it. Otherwise it would have been ten to twelve thousand to redo the whole thing. Even the lucky outcome stings at startup scale, and the unlucky one eats the runway.
The failure wasn’t the engineer. It was that there was nothing stopping him. No formal ECO process. No PDM acting as the single source of truth. Two identical-looking files on a desktop and a fifty-fifty guess.
We were managing BOMs in spreadsheets. Our CAD lived in Onshape, which has a perfectly good version tree built in, and we weren’t using it seriously. The tools existed. The discipline didn’t. That gap is the whole story of why one too many breaks teams that crushed zero to one.
Why Nobody Teaches This
Software spent two decades telling everyone to move fast and break things. Lean startup added real value, especially the discipline of defining an MVP and validating it before overbuilding. But the famous line, “that if you’re not embarrassed by your first release you shipped too late,” does not survive contact with hardware. You can’t ship an embarrassing physical product to a few hundred customers and patch it over the air.
If you’re planning to produce more than a few hundred units, you have to document your process. Not because it’s satisfying, but because the alternative is the connector story and the wrong-file story on repeat.
EVT, DVT, and PVT are terms I never learned at MIT. I picked them up on the job, later than I should have. The startups I see doing version control and documentation well are almost always the ones who’ve shipped before and learned it the expensive way. That’s the entire reason I’m writing this: so the newer founders set up these processes before the first mold gets cut, not after.
The boring work, the documenting, the version control, the ECO process, is what separates an engineer from a tinkerer. Don’t learn the expensive way.
👶 Meme Of The Week
