Stock that still balances at the end of the month.

What it is

---

The back-office half of a commerce system: the warehouse, not the shop.

Most stock bugs come from one decision made early — keeping quantity as a number in a column and updating it in place. That works until two orders arrive in the same second, or until someone asks why the count says 14 and the shelf says 11 and nobody can reconstruct what happened.

Inventory Kit treats stock as a ledger. Quantity is derived from movements, every movement carries a reason and a reference, and nothing is ever silently overwritten.

What's planned

---

• Stock ledger — in / out / adjust / reserve / transfer, each with a reason code and a reference to the order, purchase order or count that caused it. Current quantity is a projection, not a stored guess.
• Reservation inside the transaction — stock is held in the same database transaction that creates the order, with SELECT … FOR UPDATE. Two customers, one last unit, one winner. The naive version of this is the single most common way a stock system loses money.
• Multi-location — separate stock per warehouse or shop, with transfers modelled as a paired out/in so nothing evaporates in flight.
• Purchase orders → goods-in — suppliers, purchase orders, partial receiving, and discrepancies recorded rather than absorbed.
• Physical counts — count sheets, variance against the ledger, and an adjustment that leaves a trail.
• Reorder thresholds — per SKU per location, with low-stock alerts.
• Valuation — FIFO or weighted average, so the stock value on the dashboard is defensible.
• Supplier portal — suppliers see their purchase orders and confirm shipments, behind their own authentication.
• Field-level RBAC — owner, warehouse, purchasing, viewer. The warehouse operator adjusts stock but never sees cost prices.
• Admin dashboard — stock value, movements, dead stock, goods in transit, items below threshold.

What's not planned

---

This is the stock core, not an ERP. It deliberately will not include:

• A storefront or cart → that is Checkout Kit, and the two share an architecture if you need both
• Accounting, invoicing or tax filing
• Manufacturing, bills of materials or work orders
• Shipping-carrier integrations and label printing
• Barcode hardware drivers — SKU lookup is in, scanner firmware is not
• Demand forecasting

The rule is the same as the other kits: if it makes the application start, it is in; if it is your business domain, it is yours to build — on foundations that are documented and tested.

Stack

---

Same architecture as the other kits, so if you own one you already know this one.

Client — React 19, TypeScript, Vite, in both client/mui/ and client/tailwind/.

Node edition — Express + TypeScript, Postgres, JWT + bcrypt.

Go edition — Go + Gin, Postgres, standalone pkg/rbac, JWT + bcrypt.

Both editions share the same schema, the same API contract and the same SQL migrations — which is exactly why the migrations are plain .sql rather than an ORM's: two backends cannot drift from one file.

Why this kit

---

Every stock system starts as a column called quantity and a form that edits it. The rewrite comes when someone finally asks what happened between Tuesday and Friday, and the honest answer is that nobody knows.

Building the ledger version first is not over-engineering. It is the version that still tells you the truth in month eighteen.