In Part 1, we covered what a BOM is, what BOM management software does, and how the market breaks down from enterprise monoliths down to startups still living in Google Sheets. If you haven't read that yet, start there.
This post is about the harder question: when do you actually need to make the switch? And more importantly, why does your current setup work fine right up until the moment it very much doesn't?
The Spreadsheet Is Fine. Until It Isn't.
Here's the honest truth about spreadsheets: they work. For a while.
When you have one engineer, one product, and one revision, a Google Sheet is totally fine. You can move fast, iterate quickly, and not worry about process. That's not a problem; that's how early-stage hardware development should feel. Documentation for its own sake is waste. Nobody is arguing you should slow down to build a PLM implementation on day one.
The problem is that the spreadsheet doesn't break obviously. It degrades slowly, then all at once. You don't notice it until you're staring down a production run and something goes wrong in a way that costs real money.
Here's what that degradation actually looks like.
The Real Pain Points
The FrankenZip problem.
Your CM asks for your latest BOM package. You spend an afternoon assembling a zip file: the MCAD BOM export from Onshape, the ECAD BOM export from KiCad, a master spreadsheet that tries to tie everything together, a Word doc with assembly instructions, and a readme that explains which file is which. Your CM opens it, asks a clarifying question, and you realize the MCAD export you sent was from last week's revision. You resend. They open the new one and ask whether the assembly instructions apply to the new version or the old one.
This is not a BOM handoff. It's a support ticket. And it happens because you don't have one source of truth; you have five files that are supposed to add up to one.
The "which version" problem.
CAD tools version your geometry. They don't version your BOM in a way that's easy to reference later. Onshape, for example, doesn't give you a clean way to pull a BOM from a previously released revision. So when your manufacturer says "we built this to the BOM you sent in March" and something is wrong, you're digging through email to figure out what was actually in that BOM. Not a great place to be during a production issue.
The non-part problem.
Your CAD BOM knows about everything modeled in CAD. It does not know about your M3 screws, your thermal pad, your wire harnesses, your barcode label, your anti-static bag, or the foam insert in your packaging. Those items live in a separate spreadsheet, maintained separately, updated separately, and sent separately. Until they aren't, because someone forgot to update the packaging spec after the enclosure dimensions changed.
The rollup problem.
You want to know what your product costs to build at 1,000 units. So you add cost columns to your BOM spreadsheet. Except you have subassemblies that are reused in multiple places, and the quantity math gets complicated fast. Someone builds a formula that works for the top-level BOM but breaks for the subassembly view. Now you have three conflicting cost estimates and a conversation with your CFO you'd rather not have.
The "two CAD tools" problem.
Most hardware products have both a PCB and a mechanical enclosure. That means you have at least two CAD tools generating two separate BOMs. Neither knows the other exists. Every time either one changes, someone has to manually reconcile the master spreadsheet. That person is probably you. And if it's not you, it's whoever last touched the file, which means the version in your head might not match the version on Google Drive.
Documentation Isn't Bureaucracy: It's How You Scale
Here's something that takes most hardware engineers a while to internalize: manufacturing is, at its core, a logistics and coordination problem.
The engineering is hard, but the reason products fail in production usually isn't the engineering; it's miscommunication. Wrong part ordered. Old enclosure tooled. Component goes end-of-life and nobody caught it. Assembly instruction doesn't match the current revision. Wire harness spec updated in the ECAD but not in the master BOM. These aren't engineering failures; they're documentation failures.
The temptation at an early-stage startup is to skip documentation entirely. You're moving fast. You want to build, not write specs. That instinct is correct for a lot of things. But there's a minimum floor of documentation that makes manufacturing possible, and a BOM management tool helps you hit that floor without making it a project.
You enter your parts once. You track revisions as you go. You maintain a single source of truth that your CM, your suppliers, and your future self can all reference. That's not bureaucracy; that's the minimum viable ops layer that lets you hand off your product to someone else and have them build it correctly.
The alternative is catching up later, under pressure, before a production run, trying to reconstruct what was in Rev C and why Rev D changed it. That is a bad place to be.
A Note on Your CAD Tool's Built-In BOM
You might be thinking: "I use Onshape and it has a BOM. Why do I need anything else?"
Fair question. The honest answer: your CAD BOM is a good starting point, but it has real limits that matter at your stage.
On Onshape, non-part BOM items like adhesives, coatings, lubricants, and fasteners you're not modeling are restricted to Professional and Enterprise tiers. If you're on a lower plan, those items don't exist in your CAD BOM; you track them somewhere else. The gap grows as your product gets more complex.
CAD BOMs are also designed around design intent; they're great for capturing geometry and structure. They're not designed around manufacturing handoff: supplier data, approved vendor lists, cost tracking, revision sign-off, change order documentation. That's a different problem, and CAD tools generally don't solve it.
The same applies on the ECAD side. KiCad will export a BOM. It knows about your components, their reference designators, and your MPN data if you've entered it. But it doesn't know about your mechanical parts. And your MCAD tool doesn't know about your PCB. Someone has to own the combined view; right now, that someone is probably a spreadsheet that's slightly wrong.
When Do You Actually Need to Make the Switch?
This isn't a question of company size; it's a question of where you are in the product lifecycle. Here are the real trigger points:
You're preparing for your first production run. This is the moment. You're about to send your CM a package, and you want it to be clean, complete, and unambiguous. This is the last time it's cheap to get organized.
You have more than one CAD tool generating BOMs. If your product has both a PCB and a mechanical enclosure, you already have two sources of truth that need to be reconciled every single revision. That's most hardware products.
You've had a "wrong version" incident. A supplier quoted an old BOM. Your CM built to a revision you thought was superseded. Parts were ordered for a component that got swapped out in the last design review. One incident like this pays for a year of BOM software.
You're bringing on more people. The moment BOM data lives in someone's head or on someone's laptop, you have a problem. A second engineer, a contractor, a CM relationship, an ops hire: any of these is the signal.
You're sharing data with external parties. CM, suppliers, investors doing technical diligence, a co-manufacturer overseas. The moment your BOM leaves your building, version control matters.
What to Look for When You're Evaluating Options
Not all BOM software is built for you. The enterprise tools covered in Part 1 are powerful and completely wrong for your stage. Here's what actually matters if you're a hardware startup:
CAD integration: If it doesn't sync with your MCAD tool (Onshape, SolidWorks) and support ECAD BOM import, you're still stitching things together manually. That defeats the purpose.
Handles both mechanical and electrical BOMs in one place: Your product is both. Your BOM tool should be too.
Version control and change tracking built in: Not "save a copy with a new name." Actual revision history with visibility into what changed and when.
No IT setup required: Cloud-based, operational in minutes. Not a six-month implementation project with a systems integrator.
Startup-friendly pricing: Minimum spend in the hundreds per month, not $10K+ per year before implementation fees.
Fast onboarding: If you can't get your team up and running in a single session, the tool is too heavy for your stage.
The Bottom Line
Your BOM is the backbone of your product. Every person who touches your product downstream — from your CM to your suppliers to your ops lead — is working from it. When it's clean, consistent, and up to date, things go smoothly. When it's a FrankenZip of three spreadsheets and a readme, things go wrong in expensive ways.
Spreadsheets get you started. BOM management software gets you to production, and past it.
If you're a hardware startup building toward your first or next production run, oroForge was built for exactly this: a lightweight PLM platform that gets your team organized in minutes, without the complexity or cost of enterprise tools.