Use case
Inventory Management Software For Manufacturing
Manufacturing inventory is not a count of things you have. It is a count of things you have, things you have promised, and things that are currently halfway through becoming something else.
The moment production enters the picture, inventory stops being a single number. Raw materials become work in progress, work in progress becomes finished goods, and a bill of materials ties all three together so that selling one finished unit quietly consumes a list of components you may or may not have.
We sell source code you clone and run yourself, so there is nothing hosted here. For most manufacturers a dedicated product is the right call, and this page is about what separates them.
The bill of materials changes everything
What a BOM turns one number into
Purchased components and materials, counted in the unit you buy them in. Straightforward until a component is itself manufactured, at which point the BOM has levels.
Materials consumed by a production order but not yet finished goods. This is the category spreadsheets cannot represent, because the components have left stock and the product does not exist yet.
Sellable units. Selling one has to decrement the right things, which is only possible if the BOM is accurate.
Stock promised to open production orders is not available for new ones. Treating on-hand as available is how a shop floor discovers mid-run that the fasteners went to another job.
A tool that models only on-hand quantities is a stock counter. Manufacturing needs all four, and the BOM is what relates them.
Multi-level bills are where products differ most. If you make a sub-assembly that goes into a finished product, the system has to explode requirements down through the levels and roll costs back up. Tools that support only a single level force you to treat sub-assemblies as separately purchased items, which works and makes your costing wrong.
Material requirements planning is the feature people mean
When manufacturers say they need inventory software, what they usually need is MRP: given a demand for finished goods, a bill of materials, current stock, and supplier lead times, tell me what to order and when to start each job.
That calculation is the value. It is also where the data quality requirement bites, because MRP output is only as good as the lead times and BOM quantities feeding it, and both drift. A system producing confident purchase suggestions from stale lead times is worse than a planner with a spreadsheet, because the spreadsheet does not inspire confidence it has not earned.
Traceability is a separate requirement worth naming early
If you make food, medical devices, aerospace parts, or anything else where a recall is possible, you need to answer two questions: which raw material lots went into this finished unit, and which finished units contain this raw material lot.
That is lot and serial traceability, and it has to be designed in from the start. It requires recording lot consumption at the point of production rather than deducing it afterwards, and retrofitting it into a system that tracked only quantities is effectively a rebuild. If it might apply to you, treat it as a requirement now rather than later.
The options, briefly
Fishbowl appears throughout this search because it occupies a specific niche: manufacturing inventory for businesses running accounting software that does not do production. Odoo covers manufacturing with an open source core and scales into full ERP. Above a certain size the conversation becomes ERP rather than inventory, and that is a different budget and a different project.
All of these are other companies' products with their own licensing and hosting costs.
When manufacturers build
Rarely the inventory itself. What does get built is the shop floor layer: capturing what actually happened during production, machine by machine, in a form operators will use.
That is a genuinely under-served space, because the general products assume a desk and a keyboard, and a shop floor has neither. It is also where a small custom application can pay for itself quickly by feeding accurate consumption and completion data back into whatever holds the inventory.
What you would start from here
There is no inventory or manufacturing capability in this stack. No products, no bills of materials, no production orders, no work in progress, no MRP, and no lot traceability.
What the Vault template provides is the application around a shop floor tool: organizations as the tenancy boundary if you serve multiple sites or sell the tool, roles and invitations so an operator sees their own work centre, a Hono backend with Prisma and Kysely on Postgres, an admin app, and Stripe billing if you sell it.
You would write the production order and consumption records, the operator interface, and the integration back into whichever system holds the master inventory. Two practical notes: design for touch and gloves rather than a mouse, and assume the network on the floor is unreliable, which means local capture and later sync rather than a form that needs a live connection.
For the inventory itself, buy. The packs below are for the capture layer around it.
What is Hype Stack?
Every product starts with the same month of work nobody pays you for: sign-up and login, teams and permissions, taking payments, notifications, an admin panel to run the business. Hype Stack is that month, already built and tested. Start from the free open-source app, add the pieces you need with one command, and keep going on the part that is actually your idea.
Everything lands as real code in your own repository, so there is nothing to rent and nothing anyone can switch off. For the engineers: React 19, Hono, Postgres, and a desktop build, typed end to end.
See it running
Templates are curated project starters built on this stack: a layout, feature packs, a custom theme, and bonus pages. The previews below are recordings of the real apps.
Packs in this stack
Every pack ships real source code: frontend, backend, and admin surfaces where the feature needs them. The ones this stack installs come first; the rest can be composed in later.
Two ways to install features
Same features underneath, different starting point. Either command resolves what the packs depend on, copies the source into your repository, and merges the Prisma schema.
Take a template
A landing page, a design system, a themed layout, and the features already wired into it. Rebrand it, put your product in the middle, ship.
npx @hype-stack/cli template$ hype-stack compose
Compose your own design
Your design and your choices, without rebuilding auth, billing, or notifications. Tick the packs you want and the CLI wires them into the open-source starter.
npx @hype-stack/cli composeQuestions, answered
More stacks
Turn your ideas into
Real applications.
Start free and own every line you ship. When you want more, one All-Access license unlocks every premium pack and template for a year.