Chemical Inventory Management Software

Most inventory software counts units and tells you when to reorder. A chemical inventory has different obligations: it underpins hazard communication, it feeds reporting thresholds, and in an emergency it tells responders what is in the building. Ordinary stock tools do none of that.

We sell source code you clone and run yourself, so there is nothing hosted here. For a single lab or a small site, the regulatory minimum is achievable with a spreadsheet and a folder of safety data sheets, and that is worth saying before anything else.

What makes a chemical record different

The reporting thresholds are what force the purchase

Small operations manage on spreadsheets until a threshold applies. Once quantities on site cross a reporting limit, the record has to be defensible and reproducible rather than approximately right, and the aggregation has to be correct across every container in every room.

That aggregation is exactly what a spreadsheet gets wrong. Containers get added in one tab, disposed of in another, and the total that gets reported was correct on the day somebody computed it. Software earns its place here by making the current total a query rather than an exercise.

Which thresholds and which regimes apply depends on where you operate and what you hold, and it changes. That is a question for whoever handles your compliance, not for a page like this one.

What to check in any product

Beyond the fields above, three things separate the tools that get used from the ones that get abandoned.

Barcode or QR labelling on containers is close to essential, because the alternative is typing a lot number from a label that has been splashed. Reconciliation, meaning a periodic physical check that produces a list of discrepancies rather than silently overwriting the record, is what keeps the inventory trustworthy. And SDS management should be automatic: a system where somebody manually downloads a PDF each time a new product arrives will drift out of compliance quietly.

When building is defensible

Rarely for a single site, because the products in this category encode regulatory knowledge that is expensive to reproduce and risky to get wrong. Getting a hazard classification wrong in your own software is a different category of mistake from getting a stock count wrong.

The case that does come up is a chemical inventory embedded in something larger: a laboratory information system, an environmental consultancy's client platform, a manufacturer's own quality system where chemical records sit alongside batch records. In those, the inventory is a component and buying a standalone product means running two systems that disagree.

What you would start from here

There is nothing chemical-specific in this stack. No SDS handling, no GHS classification, no incompatibility rules, no threshold reporting, and no container model. Those are the category, so the gap is most of it, and any implication otherwise would be worse than unhelpful given what this data is for.

What the Vault template contributes to the embedded case is the application around it: organizations as the boundary sites and clients scope to, roles and invitations, a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing if you sell the result. Because chemical records are evidence, one thing worth knowing is that building on a relational database with a proper audit trail from the start is much easier than retrofitting one, and "who changed this quantity and when" is a question you will be asked.

You would write the container and product records, the location hierarchy, the hazard fields, the SDS attachment and its versioning, and the reconciliation flow. Treat the regulatory classification as data maintained by somebody qualified rather than logic you invent.

If you run one lab or one site, a spreadsheet plus an SDS folder may meet your obligations, and a dedicated product will meet them more reliably. The packs below are for the case where this is a component of something you are building.