David Orozco Cosio · June 2026 · 8 min read
Your spreadsheet isn't free. You just haven't received the bill yet.
Excel doesn't charge you at the moment you make the mistake. It charges you three weeks later, when your CM tells you they built to the wrong revision. It charges you the afternoon your procurement lead spends reconstructing which version of the BOM went out in March. It charges you the morning you realize the thermal pad wasn't on the master spreadsheet because nobody updated it after the enclosure changed.
The costs are real. They just don't show up as a line item until something breaks.
Your CM's Contract Already Told You This
Pull out your manufacturing services agreement and look for a clause that reads something like this: "We are not responsible for any discrepancies between your BOM, CAD files, Gerbers, and assembly drawings that affect delivery schedules."
Almost every CM contract has a version of that sentence. Most engineers skip past it during onboarding. It only becomes relevant when you send an outdated BOM and the wrong parts get built.
What that clause is actually saying: the CM will build exactly what you give them. If what you give them is wrong, the cost of scrap, rework, and delay is yours. Not theirs. Yours.
A spreadsheet-based BOM makes that clause a live threat on every revision cycle. There is no version lock. There is no audit trail. There is no mechanism that prevents you from sending BOM_master_v4_FINAL.xlsx when the model changed two days ago and the spreadsheet didn't.
The File Naming Tax
Hardware Secrets documented the pattern that every engineer on a manufacturing team eventually produces:
BOM_v1.xlsxBOM_v2.xlsxBOM_final.xlsxBOM_final_v2.xlsxBOM_final_v2_REAL.xlsxBOM_final_v2_REAL_use_this_one.xlsx
It's a joke. Until it isn't.
Excel exports have no version semantics. Every time you export a BOM from Onshape or SolidWorks, you produce a new static file with no connection to the model it came from. The only way to communicate "this is the current version" is the filename. So the filename grows, and the folder fills, and somewhere in that folder is the right file and everyone is guessing which one it is.
The cost here isn't just the six-figure tooling order that gets released against the wrong revision. It's the hour your lead engineer spends before every CM handoff doing BOM archaeology: open the Onshape document, cross-reference the last export, check whether the changes from Tuesday made it in, regenerate the file, rename it, send it. That's not engineering. That's overhead that compounds every release cycle.
The Single-Person Dependency Tax
Every spreadsheet-based BOM operation eventually produces what you could call the Chief Excel Officer: the one person who knows where the master file lives, how the formulas work, why the rollup tab breaks when you sort column C, and which of the three "final" versions is actually current.
That person is irreplaceable until they aren't. When they go on leave, you discover the knowledge wasn't documented anywhere. When they resign, the next engineer spends their first two weeks not building product but reconstructing a BOM that should have been structured from the start.
An engineer in the Onshape forum put it plainly: their workplace used Excel BOMs and the problem was specifically that the file "can be copied, altered, and overwritten" with no guardrail. The result: spacers don't get ordered, assembly halts, someone spends a day figuring out what happened.
You're not running a system. You're running a person. A person cannot be backed up.
The COGS Estimate Tax
Your CEO wants a COGS estimate. That requires a clean, current BOM with accurate costs rolled up across all subassemblies.
In a spreadsheet, that rollup is a custom formula. Someone built it. It works for the top-level assembly but breaks if you add a new subassembly and forget to extend the range. The cost figures in column K are from a DigiKey quote you pulled six months ago; the lead-time situation has since changed, and two of those components are now on allocation. The packaging BOM is on a separate tab that hasn't been touched since DVT.
You spend an afternoon reconstructing a cost estimate that should take twenty minutes. The number you hand your CEO has three caveats, two assumptions, and one part you're not sure is still in the design.
That afternoon cost your company more than a year of BOM management software.
The Reconciliation Tax
Most hardware products have both a PCB and a mechanical enclosure. That means two CAD tools: something like Onshape or SolidWorks for mechanical, and KiCad or Altium for electrical. Each generates its own BOM. Neither knows the other exists.
Every time either design changes, someone reconciles the two exports into the master spreadsheet manually. That reconciliation takes time. It introduces error. And if the person doing it is context-switching between that task and a DVT build, something gets missed.
A SolidWorks user documented a version of this failure: a procurement manager flagged a BOM showing 14 brackets when the latest assembly only had 12. The engineer went back, regenerated the export, discovered someone had updated a configuration two days earlier. Procurement was blocked. The launch slipped. All of it started with an export that didn't reflect the current model.
That scenario plays out in slightly different forms at every hardware team using CAD exports as their BOM source of truth. The mechanism is always the same: the model and the spreadsheet are separate objects, and the moment between "model changes" and "spreadsheet gets updated" is where the errors live. A real hardware BOM has layers — PCBA, mechanical, packaging — and each layer is another reconciliation surface.
What the Tax Bill Actually Looks Like
None of these costs are hypothetical. They accumulate on real timelines.
An engineer-hour spent on BOM archaeology before a CM handoff, every two weeks, across a six-month build cycle: roughly 13 hours of senior engineering time spent on file management instead of product development. At a loaded cost of $80-150/hour for a hardware engineer, that's between $1,000 and $2,000 in labor cost before anyone has made a single mistake.
Add one wrong-revision incident: a CM build to an outdated BOM, parts procured against obsolete specs, or a scrapped production run. Depending on volume and component costs, that single event can run from a few thousand dollars to six figures.
Add the onboarding cost for a new engineer who has to reconstruct BOM history from email chains and a folder full of identically named files. That's two to three weeks of reduced productivity on someone you're paying to build product.
The spreadsheet wasn't free. You just paid in installments.
The Problem Isn't the Tool
Excel is a good tool. It is genuinely good at what it was built for: financial modeling, data analysis, calculations with clear inputs and outputs. It is not a version control system. It is not a change management system. It is not a single source of truth for a product that changes every two weeks and needs to be handed to a CM with zero ambiguity.
Using it as one isn't laziness. It's the default most hardware teams inherit because there was nothing better-suited in the early days of the project, and nobody made the switch when the product started to get complicated. Understanding when a hardware startup actually needs BOM management software comes down to recognizing these trigger points before they cost you a build cycle.
The switch is simpler than most engineers expect. You don't need a $10,000-per-year enterprise tool with a six-week implementation. You need something that holds a structured BOM, tracks changes, ties revisions to approvals, and can hand off a clean package to your CM without a filename negotiation. The BOM management software landscape has options at every price point — including free.
That's the minimum viable BOM operation. It's not glamorous. It's just the part that stops the tax from compounding.
oroForge is PLM built for hardware startups: BOM management, change orders, and file storage, free to start. See how it works at oroforge.com.
