About oroForge
Somewhere around ten engineers, your BOM stops being a single source of truth. Someone updated the wrong tab. A component got substituted without a change order. A supplier lead time changed and nobody touched the master doc. The spreadsheet is still there; it just no longer reflects what you're actually building.
That inflection point is not an engineering failure. It is an infrastructure failure. The team used the tools available to them, and those tools were not designed for the problem.
We built oroForge because we kept hitting that wall, and because nothing that existed actually solved it.
The wall every hardware team hits
At three people, your BOM lives in a shared Google Sheet and everyone knows what's in it. At eight, the cracks start showing. At fifteen, you have three slightly different versions floating around Slack and nobody is entirely sure which one your CM is building from. By the time you notice, you have already shipped hardware from the wrong revision.
The enterprise options exist: Windchill, Teamcenter, Arena. They are built for companies with a dedicated PLM administrator, a six-month implementation timeline, and an IT department. That is not a startup.
The lightweight alternatives, Notion, Airtable, Jira, do not model the problem correctly. A hardware BOM is a structured document with part relationships, revision history, and links to the files and change orders that define each revision. A Jira ticket with an attachment does not capture that.
So hardware teams improvise: Google Sheets for the BOM, Dropbox for CAD files, Jira for change requests, and a shared understanding that eventually breaks down. That improvisation has a cost. It shows up in incorrect builds, late NPI timelines, and engineering hours spent reconciling part numbers instead of shipping.
Built from inside the problem
David Orozco Cosio spent over a decade in IoT hardware before founding oroForge. Distributed sensors, autonomous systems, medical devices, toys. That range is unusual. It is also the point.
IoT sits at the intersection of hardware and software. That meant building firmware and applications alongside the physical product, working through the same BOMs and change orders that any hardware team deals with, and watching what broke at scale. It also meant knowing what good software tooling looks like and why hardware teams have been shortchanged on it.
oroForge was not built by shoe-horning a software solution onto a hardware problem. It came from explicitly experiencing “hardware is hard” and knowing enough about software to make it a little easier.
The team
oroForge is not in stealth mode. The co-founder is.
A fellow MIT engineer is helping build this: a software engineer who predates the era of vibe coding. How far those days are; practically walking alongside triceratops. The combination is intentional: a hardware practitioner who has lived the problem, and a software engineer who knows how to build the tooling that fixes it.
Built for teams that are still moving
oroForge is for hardware startups and small engineering teams: two to fifty engineers, past the prototype stage, starting to deal with real supply chain complexity, contract manufacturers, and multi-person review cycles.
You get structured BOM management with hierarchical assemblies and revision control, PDM file storage with version history linked to BOM line items, and ECO change control with a formal approval workflow. The pieces that fall through the cracks between your spreadsheet, your Dropbox, and your Slack channel.
When you raise an ECO, it creates an auditable record: what changed, who approved it, when it released to production. Your CM gets the right revision. Your procurement team works from the same part list as your engineers.
No administrator required. No implementation project. A team can be up and running in an afternoon.
If you are running your BOM in Excel right now, you already know what the next six months look like. oroForge is the cleaner path forward.