An Indian garments manufacturer (men’s and kids’ apparel — shirts, trousers, shorts) needed an ERP from day one to run enquiry, procurement, production, dispatch, sales, and marketplace listings. A leading enterprise ERP was evaluated and rejected by the team for being too complicated for non-technical users. Pure Billion Technologies built a fully custom ERP, fit-to-workflow, in 3 months. The system now handles 50,000+ units per month.
The client
An Indian apparel manufacturer producing shirts, trousers, and shorts across men’s and kids’ categories. Multi-channel: own brand store, marketplaces, and B2B distribution. Operations span sourcing, in-house production, QC, dispatch, and channel listing. (Client name held back at their request — verifiable on request under NDA.)
The problem: building from day one — without an ERP that fights the team
The client was launching the brand and wanted operations to run on a real ERP from day one, not on spreadsheets that would have to be migrated later. They evaluated a leading enterprise ERP — the one most consultants and apparel software lists recommend — and went deep enough to sit through demos and a configuration walkthrough.
The team rejected it. Not because of price, integration, or features. Because of complexity.
- Every screen carried fields the team did not need, hiding the fields they did.
- Configuration was extensive, but every change still felt like a workaround on top of someone else’s data model.
- The end users on the floor — non-technical, fluent in apparel operations but not in software — looked at the interface and quietly began routing work outside the system.
“Apparel floor teams know exactly what they need to see on a screen. When an ERP shows them twenty fields to look past every time, they stop using it. The ERP is not unsuited to the industry — it is unsuited to the user.”
What “day-one ERP” actually had to cover
| Stage | What the system has to do | Who uses it |
|---|---|---|
| Enquiry | Capture buyer / channel enquiries with style, season, quantity | Sales, merchandising |
| Sampling & BOM | Define BOM for each style — fabric, trims, accessories | Merchandising, sourcing |
| Procurement | PO to fabric mills and trim suppliers, GRN, quality check | Sourcing, store |
| Production | Cutting, stitching, finishing tracking — per style, per lot | Production manager, floor |
| QC & dispatch | Per-piece / per-lot QC, packing, dispatch | QC, dispatch |
| Sales channels | Brand store, marketplaces (Amazon, Flipkart, Myntra, Ajio), B2B | Sales, e-commerce |
| Listings & inventory | Catalog push, inventory sync across channels, order pull-back | E-commerce ops |
Why we built it custom, not on top of a framework
We could have started from an apparel-flavored ERP framework. We did not, for the reason that drove the client to us in the first place: every framework forces a model. Our brief was to design the system around how this team works — not around how a generic apparel team is assumed to work.
| Dimension | Big-name enterprise ERP | Apparel ERP framework | Custom ERP |
|---|---|---|---|
| User experience | Complex, team rejected | Better, but generic apparel model | Designed for this team’s exact workflow |
| Time to first useful module | 6–9 months | 3–4 months | 6–8 weeks |
| Marketplace integrations | Available, heavy | Often partial | Built to spec for client’s channel mix |
| Customization tax | High — every change is a project | Medium — overrides feel hacky | None — the system is the customization |
| 5-yr TCO | Highest (licenses + consultant rates) | Medium | Lowest |
How we delivered in 3 months — with an 8-person team
The team that delivered this build was small and specialized. Composition matters more than headcount in custom ERP work; the wrong shape of team will rebuild the system three times before getting it right.
- 1 project manager — on-site discovery, sprint planning, client and floor-team coordination, requirements traceability.
- 1 database engineer — designing a schema that fits apparel data: SKU variants by size and color, BOM versions per style, lot tracking, multi-channel inventory.
- 1 UI/UX designer — every screen designed around what a non-technical floor user needs to see and do, not around showing the data model.
- 3 developers — full-stack delivery on a standard, supportable stack the client can hire for in future. Parallel module delivery to compress timeline.
- 2 QA engineers — testing across real production lots before each module went live.
Phase 1 (week 0–6): enquiry → BOM → procurement → production
The first slice put the most operationally critical loop into the team’s hands: enquiry capture, BOM, procurement, and production tracking. The team began running real orders through it within six weeks. This validated the schema and UX choices before the rest of the system was built.
Phase 2 (week 6–10): QC, dispatch, sales channels
QC and dispatch modules went live next, followed by channel sales — own brand store, B2B, and the first marketplace integration. Each module shipped with operations training built around the actual user, not a generic LMS.
Phase 3 (week 10–12): listings, inventory sync, reporting
The final phase brought catalog push, inventory sync across marketplaces, order pull-back, and reporting. This closed the loop: a single system from enquiry to listing, with no spreadsheet bridges.
What changed for the client
- Adoption stayed high. Floor staff kept using the system because the system was built around them, not the other way around.
- One source of truth. Enquiry, production, dispatch, and marketplace listings live in one place — no spreadsheet bridges, no manual reuploads.
- Channel sync without manual work. Catalog and inventory push to marketplaces happens from the ERP itself; orders pull back automatically.
- Scope grows without forklift upgrades. New categories, new channels, and new internal processes plug into the existing data model.
- Client owns the IP. The schema, code, and roadmap are theirs.
Why this matters for your apparel operation
If your team has looked at a recommended enterprise ERP and quietly decided not to use it, that is data — not resistance. Floor and merchandising staff abandon software that does not fit their workflow, and they are usually right to do so. The fix is not more training on the wrong system. It is a system designed around your operation.
Building or rebuilding apparel operations?
Whether you’re starting from day one or replacing an ERP your team has stopped trusting, we’ll give you an honest read on what custom should and shouldn’t cover. 30-minute call, no slides.