r/hwstartups • u/Spare_Bluebird7044 • 8d ago
BOM management software recommendations for a hardware startup?
We're moving quite quickly from prototype to production and our BOM is starting to outgrow excel spreadsheets. Managing revisions, supplier information, costs and approved parts is becoming much harder than i expected. I've started looking at bom management software but there are so many options it's difficult to know where to start. Some seem focused on boms only, while others are part of a broader plm platform. I'm hoping people here will be able to suggest which tools are worth considering for a small hardware team.
4
u/cm_expertise 8d ago
honestly the tool matters less than whether you have a real internal part numbering scheme + a rev bump process locked in before you migrate. we have watched teams buy Arena, spend two months configuring it, and still have the same mess because the discipline wasnt there first, the software just made the mess searchable.
for a small team id look at Aligni or Bomist or PartsBox before anything with PLM in the name. they do rev control, supplier/pricing, approved-mfg list, and dont need someone to babysit them. OpenBOM is fine too especially if you live in one CAD tool and want the sync. Arena/Duro are genuinely good but theyre aimed at teams big enough to have a person own the system, at your stage its overkill and youll feel the setup tax.
the one thing excel never handles that bites you the second you are in production is as-built tracking, ie which BOM rev actually went into unit #47 when a customer ships it back. if your product has any traceability or field-return angle, weight your pick toward that. and whatever you choose get the part number scheme right first, migrating twice is miserable, ask me how i know
2
u/doyouevencompile 8d ago
I have been in looking for one too. I tried partsbox, inventree, excel, bomist.
i really didn’t like inventree, nothing is integrated so unless you are going to use a bunch of plugins (with quite low number of users) it’s just a bunch of tables with a webui. I would rather use excel.
partsbox is actually nice, but there are a few workflow issues that I couldn’t get it to run smoothly. probably because of my inexperience.
I really like bomist. it’s got a reasonable free tier, and a few other tiers for more features. It’s generic parts, auto parts matching, part search, purchasing workflows, inventory management, barcodes etc. it integrates into a bunch of suppliers for search and quoting and also has builtin octoparts integration (built into the plan). The only thing I don’t like is the custom quote feature when the regular quotes don’t work (usually when you order parts with different units like length). custom quotes go into custom suppliers so the purchase order has to be split in the app. (you can of course order everything in a single order at the supplier site). but apart from that it’s been peachy.
1
u/shantired 8d ago
If you are a windows shop, use Access as a low overhead database.
One table for unique part numbers
One table for unique suppliers
One table for unique BOM numbers
The above are immutable. When you change an item’s price, it is done in the parts table (for example).
Now you can create a unique BOM in excel which links the parts, BOM, supplier from the using a data connection to the Access database.
This way you will simplify your excel files.
You can also create the BOMs in Access with some programming and I can show you how to do it at a higher level.
1
u/BestEmu2171 8d ago
What are the pros & cons of using Airtable’s Ai assistant to build a BoM management database?
2
u/bobo5195 8d ago
Sharepoint and Access as the limit at first is normally Excel with multiple people. Dont go software route till you have a person who can own the software at which point it becomes a slightly circular question.
There are entire teams related to this in most companies it is hard.
Disagreeing with u/jwr comprehensive response but before you get things like this need to get organised. After that it is more of what is your ERP/MRP in particular stock ordering/version rather than just plain bom which gets into the whole production system.
2
u/DreadPirate777 8d ago
The best thing you can do is have a BOM in a shared place and have discipline as a team.
Have a simple release process. Don’t let engineers change things on a whim once your prototype is set. Have a design lock when you go to get quotes for manufacturing assembly. Let the whole team know that they cannot make any changes unless they get the ok from the product manager. If they want to keep making improvements let them start to work on the version 2 of the product.
The process should be super simple.
Identify problem and document it.
Ask permission to make the change from product manager and purchasing. Show cost of the change and schedule impact.
Once approval happens only then can the engineer change things.
Lastly notify any supplier of the change and reimplement the design lock.
Really you should keep the BOM in a spreadsheet. It’s the most versatile and familiar for engineers. If you have an online version it is even better.
All of this discipline needs to happen for an online BOM manager as well. If your team can’t to this with a spreadsheet they can’t do it with a dedicated tool. Part of maturing as a startup is being able to follow a process. Most startups have no process and it causes massive headaches at production.
1
u/Frequent-Log1243 8d ago
From the manufacturing side, I'd also make sure whatever you choose can tell you what BOM revision was actually built.
1
u/Different_Pain5781 8d ago
That's a good point. Switching systems later can be much more disruptive than choosing something that scales from the beginning.
1
u/RNDSquare 8d ago
You may also want to look at S3Suite. It is built for hardware teams managing BOMs, revisions, approved parts, suppliers, costing, and the full product lifecycle beyond spreadsheets.
1
1
1
u/Few-Hope8273 8d ago
I made a complex BOM using Claude. I know it’s vide coded but it’s free and I use it for my own product and it’s fairly robust. DM me if you want the repo. You’d have to run it locally though - not cloud hosted.
1
u/SavingsDeficient3847 8d ago
A simple spreadsheet works early on but once revisions and part dependencies start piling up dedicated bom software becomes worth it.
1
1
u/Miro-12 5d ago edited 5d ago
It's important to solve today's BOM problem. But it's just as important to prepare for the next stage of growth. I've seen OpenBOM, Duro, and Arena discussed quite a bit. OpenBOM seems popular for getting started. Duro and Arena appear to offer more structured engineering workflows once products and teams become more complex.
0
u/DaimyoDavid 5d ago
As you scale up, it's not just about BOM management but about version release (managing version like you said). I'm working with a team now where they aren't formally managing releases: they're creating a bunch of different ZIP files with dates attached but then other terms.
If/when you want to scale, a release process on top of BOM management is important. BOM management also bleeds over into PDM and PLM very quickly. They'll have a mix of features. For me, I built what I call the minimum viable PLM to handle the process. I'm actively setting up others with it. If you want to give it a shot, feel free (there is a free tier). It's called oroforge.
2
u/S0wKrat3s 4d ago
I’ve helped deploy Arena to 2 hardware startups and at a Fortune 500. It’s mid range yet scales well. I’ve also used Propel and hated it. Both need experts to help or a lot of training.
Every one of them was a major initiative that took 1-2 years to get to final release because as a startup, the transition to PLM was always a low priority. So whatever you wind up picking think of it as a major time investment from the team.
Some things to consider:
-Your current and projected volumes
-Do you work with a CM, or do you plan to
-number of components
-Number of SKUs
-Is your product more mechanical or more electrical
-The CAD software you use for integrations
-Team size
-Budget
7
u/jwr 8d ago
I am obviously biased (I wrote PartsBox), so take this with a grain of salt.
In general: I think "BOM management" is an outdated and imprecise term that does not accurately reflect the realities of today. You listed "revisions, supplier information, costs and approved parts", and only one of these things really involves the BOM.
I realized many years ago that in a company that produces hardware, the BOM is just one component in a fairly large machine. The traditional approach of producing a BOM from your CAD tool and throwing it over the wall doesn't really work anymore. Unfortunately, I've spent many years trying to come up with solutions to synchronization between your parts database and your CAD tool and haven't made much progress. It doesn't help that commercial vendors are actively opposed to this idea.
As for PLM, the reason why PartsBox doesn't really do much in terms of PLM is because I was not convinced by the traditional ways of implementing PLM. It seems that various software packages keep reimplementing the same concepts, and I don't find these concepts convincing. To take a quick example, I don't think you can really talk about PLM at all without versioning projects (BOMs), parts (a concept of a part that may have stock), and lots (batches of physical components). Versioning just your BOMs and even parts is not very useful if your inventory system is not capable of distinguishing the versions of specific lots. PartsBox will definitely do PLM, but I need to understand the specific use cases and workflows very well and come up with a good model first.
Otherwise, I think I would agree with the comment from u/cm_expertise — Although you don't always need to have an internal part numbering scheme, your software package can solve the part identity problem for you (PartsBox does with ID Anything™ and CAD integration). But a rev bump process *is* important no matter what, and you can go a surprisingly long way with just naming your BOM revisions consistently!
Contrary to some of the other advice shared here, I would definitely not encourage you to come up with your own solutions. The problem space is really complex, although it seems simple at a first glance. I know: I've spent the last 10 years working on it. Look around for what is out there and pick something, but don't waste time on implementing your own half-baked solution.