A bespoke garment manufacturer was running JIT fabric ordering on WhatsApp and spreadsheets. We fixed it in two weeks.

The business and why the process was breaking

Bespoke garment manufacturing is not a forgiving business. Every order is unique. Fabric is sourced just-in-time from a vetted network of 10+ suppliers — ordered only when a customer order is confirmed, in the exact quantities needed, because carrying excess stock is waste the margins cannot absorb.

In theory, JIT is elegant. In practice, for this SE Asia manufacturer, it meant their purchase team was the human glue holding together a chain with no system underneath it. Every day looked like this:

• Consolidate fabric requirements from sales orders into a spreadsheet
• Break the consolidated list into individual supplier orders
• Send each order 1-to-1 via WhatsApp or email — one supplier at a time
• Follow up manually on confirmations, delivery timelines, replacements
• Receive fabric, manually verify against what was ordered, enter into the ERP
• Chase outstanding deliveries, raise replacement orders when fabric arrived damaged or short

Four people. More than twenty hours of this, every day.

Two specific failure modes stood out that a simple "better spreadsheet" couldn't solve.

Problem 1 — fabric damaged or wrongly cut on the floor

Occasionally a tailor would damage fabric or cut incorrectly. New fabric had to be ordered, and the cost was absorbed by the factory. But there was no trail. No record of which order triggered the replacement, who cut the fabric, why additional material was needed. The same mistakes could repeat. Training couldn't be targeted because the data didn't exist.

Problem 2 — fitting orders over-committing fabric

For a bespoke order of, say, four suits, the process was sometimes to order fabric for all four upfront — even though the customer first needed to confirm fit on one before the remaining three were cut. That meant fabric for three suits sitting on the floor in a holding state, committed but not yet needed, waiting for a customer confirmation that might take days or weeks.

Both problems shared the same root: no system meant no visibility, and no visibility meant no ability to make smarter decisions about what to order, when, and why.

This is the broader pattern we cover in how to unify ERP, CRM, and operations data — five tools work fine in isolation, but the moment a decision needs information from two of them, the whole operation stalls on a person walking between desks.

What we built: a low-code Power Apps supplier portal

The solution is an integrated supplier portal built on Microsoft Power Platform, with Dataverse as the data backbone and Power Automate handling notifications and workflow triggers. The ERP integration was a Day 1 requirement — data flows automatically, nothing gets manually re-entered.

We applied the MECE framework during the analysis phase to ensure the modules covered the full process without overlap or gaps. Six distinct modules came out of that exercise.

The implementation was not straightforward

The MVP was live in two weeks. That timeline is accurate — but it doesn't capture what the cutover actually required.

The most significant challenge was that on any given day, orders were mid-flight in the old system. WhatsApp threads were active. Partial deliveries were in transit. There was no clean break point. We had to establish a hard cut-off date, communicate it to all suppliers, and ensure the purchase team understood that from that date forward, everything went through the portal — no parallel running, no exceptions.

Team training was also non-trivial. The purchase team needed to be precise about quantities in the new system — because unlike a WhatsApp message that could be casually corrected in the next message, a system entry triggers a supplier notification and an ERP record. The discipline required was different. That adjustment took deliberate coaching, not just a training session.

What changed

What's being built next

The accounts reconciliation module currently flags mismatches for human review. The next phase introduces ML-driven auto-reconciliation — matching purchase orders, receipts, and supplier invoices automatically, escalating only genuine exceptions. This is being developed using Claude and is in active build.

The goal is to take the reconciliation workload from a daily review task to an exception-only process — the same philosophy that drove the original build, applied to the most manual remaining step.

The invoice agent that came out of this is also where the broader pattern showed up: how this one workflow changed how the team works — procurement, the production floor, and the owner all started asking what could be codified next.

What this illustrates about low-code in manufacturing

The technology here — Power Platform, Dataverse, Power Automate, MS Graph for authentication — is not exotic. What made this work was the analysis before the build. Using a structured framework to map the full supply chain process identified six distinct problem areas that each needed a different solution. Building a single "order management app" without that analysis would have solved one of the six and left the rest.

The two-week timeline was possible because the platform handles infrastructure — authentication, data storage, mobile interfaces, notifications — and the build focused entirely on the business logic. That's the genuine value of low-code in a manufacturing context: not that it's fast, but that it lets a small team focus on solving the right problems rather than rebuilding plumbing.