Module Map

What this prototype demonstrates, what is designed but not built, and what a production system would add. Use it to agree scope before any of it is engineered.

The golden thread

Follow it end to end — the same data moves through every screen
Configure a line→ Demand→ Run MRP→ Planning grid→ Exceptions→ Cut plan→ Purchase orders

Change a width in the configurator and the fabric yardage, the shortage list, the pegging tree, the nesting layout and the purchase suggestion all move together — because one parametric BOM engine and one MRP engine feed every screen. That is the thing to test: it is not a set of mockups.

Phase 1 — built and working in this prototype

19 screens · real engines

Phase 2 — designed, not built

next scope

Phase 3 — beyond the core

later

What this prototype is not

Stated plainly so nothing is assumed. There is no backend, no database and no authentication. Nothing persists beyond the browser session — the “Reset demo data” control in the sidebar clears it. There are no live supplier, accounting or shipping integrations, and nothing is ever sent anywhere.

What is real is the logic. The imperial arithmetic, the parametric BOM formulas for all six product families, the MRP engine (low-level coding, gross-to-net, lot sizing, calendar-aware lead-time offsetting, pegging, exception generation) and the nesting optimiser are working implementations running against a seeded dataset of . They are verified against hand-worked industry examples, including the published drapery yardage calculation and the documented 1 3/8″ inside-mount roller deduction.

A production build would keep this logic and put a real database, API, authentication and integrations underneath it. The design and the domain rules are the part that is hard to get right, and they are the part that is finished.