Part 1 of 3: Why hardware startups are flying blind and don't know it yet.
You sent the files. You're pretty sure you sent the right ones.
Three weeks later, parts come back from the CM wrong. Or a component you've been designing around just went end-of-life. Or you're staring at two versions of the same BOM in two different places and you genuinely cannot tell which one is current.
Sound familiar?
If you're building hardware at a startup, it probably does. And here's the uncomfortable truth: this isn't a you problem. It's a tooling problem. Specifically, it's the absence of one category of tooling that you probably haven't heard of: product lifecycle management.
Most hardware startups don't have a PLM. Most don't know they need one.
Ask a founder at a 10-person hardware startup what PLM they use and you'll get one of a few answers:
- "What's a PLM?"
- "We use Onshape / Altium / SolidWorks"
- "We have everything in Google Drive"
- "We have a spreadsheet that [name] manages"
Fair enough. So: what is a PLM?
Product lifecycle management is the system that sits between your CAD tool and the rest of your business. It's where your BOM lives in a single, versioned source of truth. It's what tracks engineering changes, manages part revisions, flags obsolete components, and gives everyone on your team — including your CM, your firmware engineer, and your suppliers — visibility into the same current state of your product. Think of it as the operating system for your hardware development process.
None of the answers above are PLM. And that gap between the CAD tool where you design and the actual management of your product data is where things quietly fall apart.
Your CAD tool is good at one thing: geometry. It wasn't built to track which version of your BOM went to which supplier, flag you when a component goes obsolete, manage an engineering change order, or give your CM and your firmware engineer a shared source of truth. That's not a knock on your CAD tool. That's just not what it does.
The result is that most hardware startups operate on a patchwork of spreadsheets, shared drives, and collective memory. It works until it doesn't.
The moment it breaks
The Onshape community is unusually candid about this. Engineers describe spending 20+ hours a month manually cascading revision changes up a product structure. Teams describe multiple conflicting versions of a BOM circulating simultaneously, nobody sure which is right.
One engineer put it plainly: "At some level, the solution is a real PLM system."
The pattern is consistent: a team scales past 3 to 5 people, or they bring on a contractor, or they start working with an overseas CM, and suddenly the informal system that worked on a team of two starts producing expensive mistakes.
Wrong parts get ordered. Right parts get ordered to the wrong spec. A supplier quotes against a BOM that engineering changed last Tuesday. A component you've built around quietly goes end-of-life on Digi-Key and nobody catches it until you're three weeks from a build.
These aren't edge cases. They're the default outcome when you're growing fast without the right infrastructure.
"But isn't PLM for big companies?"
This is the most common objection and it's understandable. The PLM tools you've heard of — Arena, Windchill, Teamcenter — are built for teams with dedicated PLM administrators, six-figure implementation budgets, and months to spend on onboarding. They are, genuinely, not for you.
But the need for PLM isn't a function of company size. It's a function of product complexity. The moment you have more than one person touching a BOM, more than one supplier, more than one hardware revision in the field, you have a PLM problem. You just might not have the vocabulary for it yet.
The category has a tooling gap right at the startup and SMB level. Founders end up duct-taping together CAD tools, spreadsheets, Notion, and Slack threads to approximate what a real system would do automatically. It's expensive in engineering hours and even more expensive when it breaks at the wrong moment.
What this series is about
This is the first in a three-part series. We're writing it because it's the exact problem oroForge was built to solve.
In Part 2, we'll get into how BOM management and PLM should actually be used as a strategic tool — not just a filing system — and what that looks like in practice for a lean hardware team.
In Part 3, we'll talk about how AI changes the equation: not by automating your BOM, but by helping your team make better decisions faster, based on the workflows that actually matter to you.
The goal with oroForge is simple: give hardware startups and scale-ups the PLM infrastructure they need, without the overhead they can't afford. Fast to start. Built to scale. No consultants required.
If that sounds like something your team needs, we'd love to show you what we're building.
Get early access at oroforge.com
Next up: Part 2 — Your BOM Is a Strategy Problem, Not a Spreadsheet.