The Gap Between Factory Operations and Software
Bangladesh's garment industry is one of the most operationally intense environments in the world.
Raw materials arrive from many suppliers. Production runs across knitting, dyeing, finishing, each with its own workflow, quality checkpoints, and material consumption. A large workforce works in shifts. Inventory moves fast and must stay accurate at every stage.
Most mid-sized manufacturers still run this complexity the way they always have: spreadsheets, physical registers, WhatsApp between supervisors, and institutional memory held by a few experienced people.
It works, until it doesn't.
A shipment slips because nobody saw inventory running low until it was too late. A payroll dispute takes days to untangle because attendance lives in one place and salary math in another. A batch vanishes between knitting and dyeing because the system of record is a notebook.
In 2021, Texeurop, a mid-sized textile manufacturer in Gazipur, decided to replace those disconnected habits with one integrated ERP built for how the factory actually ran.
I was on the engineering team that built it.
Why factory software is different
Before we wrote serious code, we spent time on the factory floor. That wasn't optional. It was the only way to learn what the software had to do.
Factory operations have a logic that doesn't drop cleanly into a requirements doc. The people who know it best are supervisors and floor staff who rarely think in data models or API endpoints. They think in batches, rolls, shifts, and physical movement.
Turning that reality into architecture is the core challenge of factory ERP. Get it right and the system melts into the workflow. People use it because it matches how they already think. Get it wrong and the system fights the workflow. People route around it, data rots, and the ERP is shelfware in six months.
Three things became obvious from that time on the floor.
1. Inventory is not "simple stock"
Yarn, fabric, dye, chemicals: they carry attributes that matter operationally: batch numbers, supplier codes, quality grades, physical bin or zone. Quantity alone is only half the picture; without those attributes, the system stays partially useful at best.
2. Production tracking must follow the material, not only the order
When a yarn batch moves from knitting to dyeing, the system must answer: where is this batch now, and what has been done to it? Generic inventory products aren't built for that handoff.
3. Factory HRMS ≠ office HRMS
Shift attendance, overtime, worker categories, pay structures, leave: in a plant, absenteeism directly hits output. That doesn't map neatly onto HR tools designed for desk workers.
Those three insights shaped the whole architecture.
Three modules and what they actually required
Inventory management
The inventory module had to cover the full material lifecycle: supplier receipt → production consumption → finished-goods dispatch.
Goods-in meant more than quantity: batch identity, supplier context, inspection status, warehouse location. When a knitting supervisor needed yarn, they could see what was available, where it sat, and what had cleared QA.
Movements were tracked warehouse → floor, knitting → dyeing, dyeing → finished goods, so leadership could see material flow without chasing supervisors for manual reports.
Minimum stock thresholds and alerts gave procurement lead time before a line went idle. In a plant, a late raw-material shipment is not a spreadsheet problem; it's downtime.
Knitting module
Knitting tied production runs to specific raw-material batches. If quality blew up later in dyeing or finishing, you could trace back to the exact yarn batch and run.
Work orders carried machines, targets, specs and compared actual output vs plan so supervisors saw progress without a parallel status ritual.
Inventory integration went both ways: consuming yarn updated stock automatically; transferring greige to dyeing recorded the handoff and batch location/status in one motion.
Dyeing module
Dyeing is high variance: the same greige can yield different outcomes from recipe, temperature, time, operator practice. To keep quality consistent, you need process parameters tied to outcomes.
We recorded dye batches, chemicals, time, inspection results alongside production so quality could link defect patterns to specific runs and parameters, not guesswork.
Knitting → dyeing stayed continuous: no re-keying, lower risk of losing a batch in the departmental gap.
The hardest problems
Mapping the floor into software
The hardest work was translational, not cosmetic "tech." Supervisors don't narrate work as tables and foreign keys. They talk about things, places, and moves.
It took weeks of observation to internalize that a "batch" on knitting is not the same abstraction as a "batch" in dyeing. Same word, different meaning. Getting that wrong in the schema would have confused everyone.
We anchored the model on persistent material identity: a single identifier following stock through every stage, whatever each department called it. That gave the system one language that matched physical reality.
Raw, WIP, and finished goods in one coherent model
A garment plant isn't one warehouse. Raw materials, WIP at several stages, and finished goods coexist. Different rules, different views. The design had to keep them distinct (so a warehouse lead could read raw without wading through FG) while staying one coherent model in the backend and app layer.
Replacing habit with deliberate entry
The underestimated risk is people: moving teams from muscle memory and spreadsheets to explicit data entry.
Floor staff are not office workers; many had limited prior software use. The bar was practical: a supervisor should log production output in under ~30 seconds on a modest device, after short orientation.
That constraint drove UI and flow: drop non-essential fields, order steps to match physical sequence (not what looks tidy in ERDs), and use clear confirmation before save so errors are caught without CS degrees.
What building for manufacturing teaches you
Factory ERP forces you to design for someone under time pressure, in noise, attention split between screen and machine.
Office users sit, click, read errors, workaround. Floor users stand at lines and decide in real time. If the tool slows them, they drop it.
That pressure makes you sharper everywhere: when you've designed for the hardest users, easier contexts feel simpler.
It also reinforced a rule I still use: the best operational systems come from engineers who understand reality before they design abstractions. The floor taught us things no requirements PDF would have held. That gap is often what separates adopted software from abandoned software.
Closing
If you're building operations software for manufacturing, a plant, or any place where users aren't at desks, you're solving for adoption under constraint, not just features.
I've shipped at factory-floor depth, and I care about the difference between software that sticks and software that dies in the notebook shadow.
If this resonates, leave a comment with your own manufacturing or ERP war story, or reach out if you want to compare notes on what you're building.
Top comments (1)
If you’re working on ERP or operations software, I’d love to compare notes—happy to discuss architecture, data modeling, or adoption challenges. Drop a comment and I’ll continue the conversation.