WARDROBE PLM: An ERP for Apparel Manufacturing

WARDROBE PLM: A 19-Module ERP for Apparel Manufacturing

A seven-year build that took an apparel manufacturer of 5,800 employees from spreadsheets and untraceable inventory to a single integrated platform across 20+ departments.

Role: Software Engineer → Head of Software

Timeline: 2016–2023 (7 years, from first module to full platform)

Stack: Laravel, PHP, MySQL, Vue.js, REST APIs, RBAC, Linux, Nginx

Client: Apparel manufacturer, 5,800+ employees, 64+ production lines

The problem

The company ran on spreadsheets and disconnected department tools, and the consequence wasn't inconvenience — it was that leadership could not confidently answer fundamental questions about their own business:

1. How many employees were actually working in the factory and receiving salaries each month?
2. Was payroll accurately reflecting the active workforce?
3. How much production was completed each day?
4. How much fabric had been cut?
5. What inventory actually existed in the stores?

Critical operational data was unavailable, inconsistent, or maintained manually. Inventory records were unreliable to the point that approximately 160 tons of yarn in the yarn store could not be traced accurately through the existing system.

Constraints

1. The plant could not stop. Every module had to go live alongside the manual process it replaced, then take over once trusted.
2. Users ranged from finance staff to floor supervisors with limited computer experience.
3. Historical data going back 13+ years had to migrate without loss.
4. No budget for a commercial ERP licence — this had to be built and maintained in-house.

Approach

Modular architecture over big-bang. Rather than a single monolith delivered in year three, I designed the platform as independent modules sharing a common data core and auth layer. Each could ship, be adopted, and prove value on its own. Merchandising went first because it sat upstream of everything else.

A single source of truth for master data. Products, materials, suppliers, and cost centres were normalized into one schema that every module read from. This was the change that made cross-department reporting possible at all — before it, each department's version of "the same" item had different identifiers.

Role-based access control from day one. With finance, HR, production, and merchandising in one system, RBAC was foundational rather than retrofitted. Permissions were modelled on organizational roles, so onboarding a new supervisor meant assigning a role rather than configuring dozens of individual permissions.

Reporting as a first-class module. Rather than bolting reports onto each department, I built a reporting engine over the unified schema, with optimized query paths and materialized aggregates for the heavy production and costing views.

Modules delivered

Merchandising · Production Planning · Production Tracking · Inventory · Commercial · Quality Control · Shipment · Finance & Accounts · HR · Payroll · Supply Chain · IPE · Knitting · Wet Processing · Vehicle Management · Printing & Embroidery · Design & Development · IT · Admin & RBAC

Results

Departments became connected. Inventory became traceable. Production became measurable. Payroll became transparent. And executives gained real visibility into the business through accurate reports and dashboards — for the first time.

What this actually taught me

I went in treating this as a software problem. It wasn't. The code was the straightforward part — the hard part was that the organization didn't have reliable data to build on, and no amount of well-architected software fixes that on its own.

That 160-ton figure is what reframed the project for me: you cannot digitize a process nobody has agreed on.

So the real work turned out to be understanding fragmented business processes, rebuilding workflows, establishing data integrity, defining standard operating procedures, earning trust department by department, and driving adoption across the organization. I underestimated all of it at the start.

What I'd do differently: I'd front-load the process discovery and data-integrity work rather than treating it as a prerequisite to clear before the "real" build. Every module I designed around assumptions rather than observed operations had to be reworked. And I'd budget change management as a first-class workstream with its own timeline — not as something that happens informally alongside development.

The lesson that stuck: the hardest part of ERP implementation is not software development. It's transforming operational chaos into structured, trusted, actionable information

Building something similar? I work with organizations that have outgrown spreadsheets and need a system built around how they actually operate.

Get in touch → softshamim.com