Your BOM is not a process. It is an ingredients list. Not even a recipe, really: a recipe at least tells you what to do with the ingredients. A BOM just tells you what you have. (If you're building yours from scratch, here's how.)
It is not a process until you have a way of versioning it. Everything before that is writing it down. Everything after that is operations.
Here is what that progression actually looks like, and when each layer starts to matter.
Cut Corners Early. Know When to Stop.
When you are first building a prototype, your BOM is a reminder list. Part names, supplier links, unit cost, a note about lead time. You are one person, everything lives in your head, and that is appropriate for the stage you are in.
You might want to cut some corners early to move a little faster. That is fine. But you need to know when to start implementing, because the triggers are specific and they arrive faster than most first-time founders expect.
A Google Sheet works here. It even has versioning.
But something changes the moment you send a file to a vendor.
The Moment You Upload a File to Xometry
The first time you order a sheet metal part or a 3D printed bracket from a digital fabrication shop, you need to know which version of that file you sent. Not your entire BOM. Not even the full assembly. Just: what revision was that part?
Because you are going to iterate. You will change the bracket. You will re-order it. And when the new parts arrive and they do not fit with the old ones, you need to know exactly where the divergence happened.
This is part revision control. It does not have to be complicated. It just has to exist.
If it does not, you will spend hours reverse-engineering your own design history. A file named bracket_final_FINAL_v3_use_this_one.step is not a revision. It is a warning sign.
When You Add an Engineer, the Problem Changes
Hardware engineers are incredibly opinionated. They have their ways, they have their methods, and they will start setting up their own processes from day one whether you ask them to or not. That is not a problem. The problem is that the "why" behind their decisions lives entirely in their heads.
When you hire your second engineer, the challenge shifts. It is no longer just about revisions; it is about traceability: knowing who made a change and when.
At a startup, that person is probably not documenting why they made those changes. And that is okay. But you need to know who to reach out to when something breaks six months later and you need to understand a decision made on a Tuesday afternoon.
A BOM with no ownership data will eventually gaslight you. Not because anyone did anything wrong, but because institutional knowledge evaporates when it has nowhere to live.
Manufacturers Don't Care Who Designed It
Your contract manufacturer does not care about your team's change history. They care whether they are making the right part.
Revision control matters to a CM for one reason: if they cut v1 when you meant to send v2, the parts will be wrong. If it was your fault for sending the wrong file, you will still be upset. And the manufacturer knows it.
A manufacturer's job is to build exactly what you give them. Your job is to give them something unambiguous: "bracket-001 rev B," not whatever was last saved to your desktop. That's also where eBOM and mBOM start to diverge — the version you designed against and the version your CM is actually building from are not always the same document.
When your BOM references custom parts, every one of those parts needs a clear revision. Off-the-shelf components carry their own manufacturer part numbers; that versioning is handled for you. Anything custom is entirely on you.
When Google Sheets Hits Its Ceiling
Google Sheets has version history. You can roll back, you can see who made a change, and for a while that is enough.
It stops being enough when you need to tie a BOM revision to a change reason: why did this change, who approved it, and what else was affected. That context does not live in a cell diff.
This is when the ECO process starts mattering — and knowing when to actually turn it on matters as much as knowing it exists. An engineering change order is not bureaucracy; it is the formal link between "something changed" and "everyone who needs to know, knows." Without it, your BOM history is a timeline with no annotations. You can see that something changed; you cannot understand it.
That gap is what PLM is actually solving. Not the BOM itself: the process around it.
Building Something Right, Many Times
Engineering is not about building a thing once. At least not product engineering. It is about building something right many times, and that requires repeatable process.
You do not need all of this on day one. The triggers are clear: first vendor contact, first additional engineer, first production run. Each one introduces a new class of ambiguity your BOM alone cannot resolve.
Start with part-level revision control. Add ownership tracking when you grow the team. Layer in formal change management when you start manufacturing seriously.
If you want to see what a production-ready BOM looks like at each of these stages, this post on real-world BOM structure walks through the data field by field.
oroForge is built to grow with this process, from first revision to full ECO workflow. See pricing →
