Inventory management software design

The key facts

• The design order: invariants → data model → interfaces. Screens drawn before the model are rework with better typography.
• The core invariant: on-hand equals the signed sum of movements, at every committed transaction — everything else is built on it.
• The interface principles: readable density, state at list level, forms that refuse bad data before saving.
• The honest exit: these decisions are exactly what maintained products have already made and survived — the build-vs-buy arithmetic prices the choice.
• The full picture: how the inventory record works is the hub page for everything above.

The invariants come first

Design starts with the statements that must never be false, written precisely enough to test: on-hand for a variant at a location equals the signed sum of its movements; a movement always names an actor, a timestamp and a reason; a cancelled reservation returns its stock in the same transaction; no order ships beyond its allocation. Three to six such sentences are the real specification — features can be argued about, invariants are kept or broken.

From the invariants the data model falls out almost mechanically: products and variants, locations, an append-only movement table (the only thing that changes stock), orders and their lines, purchase orders, and the derived views — on-hand, on-order, reserved — that are computed, never stored as editable balances. The schema walkthrough builds it table by table, and the ER diagram draws the relationships.

The interface, designed around the work

The unit of work in inventory software is the list — products, orders, receipts — so the design centres on lists that carry their own state: on-hand beside allocated beside on-order, order stage visible without opening the row. Forms are the second pillar, and their job is refusal: quantities that would oversell, movements without reasons, receipts against no order — stopped at entry, not discovered at the stocktake. Workflows are the third: receiving, counting, picking are repeated hundreds of times a week, so keyboard flow and sensible defaults beat novelty in every evaluation that involves an actual shift.

What the design should resist: consumer-style simplicity that hides operational columns. Hiding allocated stock from a list does not simplify the work; it moves it into someone's memory.

The decisions that make or break the build

Concurrency at the last unit. Two allocations, one remaining piece — resolved by database serialisation, not application optimism. The design answer must exist before launch, because the failure is discovered live.

The cancel path. Reservations release atomically; freed stock is promiseable immediately. Phantom allocations — the classic homemade-system bug — are a design flaw, not a runtime accident.

Deliberate approval. Stock deducts when a human approves the invoice, not when the order is typed; intent and fact stay separate.

The tail, priced before building. Hosting, patching, backups, and every future requirement — owned forever by the builder. These decisions are precisely what maintained products have already made and survived; the LLD companion takes this design to code level for those continuing, and the KPI layer shows what the finished system should be able to measure. We build BSimple, so weigh that: it implements this design as maintained cloud software from $180/month AUD — the trial is the full product, and the fastest design review available.