AI for a 200-year-old industry: what we learned automating textile

Textile is one of those industries that looks simple from the outside (you buy yarn, you make cloth, you sell it) and turns out to be a nightmare the moment you try to put it in software. Units that aren't standardised. Widths that vary. Dye-lots that have to be tracked separately for the same SKU. Job-work flows that span multiple GSTINs. Paper chits in Hindi that summarise an entire week of production.

We started Paraslace, our textile vertical, by spending eighteen months inside a real manufacturing unit (Paras Lace, the founder's family business) and writing software that survived contact with karigars, mills, and the GST portal. This is what we learned.

The things textile software has to get right

The list, in roughly the order they bit us.

Units that aren't standardised. Some fabric is sold by the meter. Some by the kilogram (because the buyer cares about weight, not length). Some by the piece. Some by the "thaan" (a roll, which is ~100 meters give or take). Conversion isn't always clean. A 44-inch-wide fabric vs a 58-inch-wide fabric at the same meter count is a different quantity of fabric.

Width math. Fabric width affects pricing, conversion, and yardage. Software that doesn't model width as a first-class field will be wrong constantly. Most off-the-shelf ERPs don't.

Dye-lot batching. The same SKU in two different dye-lots is, for any serious buyer, two different products. You can't ship a mixed dye-lot order. Inventory tracking has to know this.

Job-work flows. A manufacturer sends raw fabric to a job-worker (printer, embroiderer, finisher) and gets it back as finished goods. That's a transfer of stock, not a sale, but it has GST implications under Section 143. Most ERPs flatten this into a normal transaction and the accountant has to fix it monthly.

Paper chits. A karigar gets a paper chit at the start of the day. They produce against it. They return it with a hand-written quantity at the end. That chit is the source of truth for production, payroll, and inventory adjustment. Software that ignores paper chits will be ignored by the floor.

Multi-GSTIN within one operation. A single textile business often has a manufacturing GSTIN, a trading GSTIN, and a job-work GSTIN. Sometimes in different states. Internal transfers between them are real, taxable events.

None of this is in a textbook on ERP design. All of it is in every textile factory in India.

What AI changes

The interesting question for 2026 is what genuinely new things AI lets us do, versus what is just "do the same thing faster".

Three things land differently now:

Paper chits become structured data. A photo of a hand-written chit in Hindi or Gujarati goes to a multimodal model. The model returns structured JSON: karigar name, machine, items, quantities, time. Five years ago this needed a custom OCR pipeline and an army of corrections. Today it's a prompt and a few examples.

Voice notes become orders. Customers send voice notes ("bhai 50 meter chiffon, white, Friday tak chahiye"). Whisper transcribes, the agent parses. We've gone from "transcribing voice notes is too unreliable" to "voice notes are routinely the cleanest order channel" in two years.

Photos become product matches. A customer sends a photo of a fabric and asks "kya yeh available hai". The model embeds the photo, matches against our product catalogue, returns the closest matches with confidence. This is now a reasonable feature, not a research project.

Job-work GST gets cleaner. GSTR-1 reconciliation for job-work transfers used to be a manual hellscape. The AI layer we discussed in our GST post handles the labour of comparing what we sent against what the job-worker reported, surfacing mismatches in minutes instead of hours.

What still needs human eyes

Textile has a stubborn human-loop layer that we don't try to remove.

Quality calls. "Is this dye-lot acceptable for this buyer." That's a textile expert's job. We surface the comparison; a human approves.

Pricing in volatile periods. When yarn prices move 5% in a week, customer pricing has to be re-negotiated, not auto-set. The agent drafts; the owner approves.

Karigar trust calls. Karigar A is reliable. Karigar B used to be reliable but has been slow lately. Software doesn't make this call. The supervisor on the floor does.

Mill capacity bargains. When the captive mill is overloaded and the order is hot, somebody calls another mill. That conversation is not happening through software.

The pattern is consistent: software handles the bookkeeping and the comparison work. Humans handle the relationship work and the judgment.

A textile business is not a tech business with fabric. It is a relationship business with very complicated accounting. The software that wins is the software that respects this.

What Paraslace actually does

Concrete, for the curious.

Paraslace is the customer-facing brand for our textile vertical. It runs on the Krypto Forge Platform (Odoo backbone, Next.js front, ACL in between, all the things we wrote about separately).

It handles:

• Order intake from WhatsApp (including voice and photo), karigar app, and dealer portal.
• Inventory at the dye-lot level, with width as a first-class field.
• Job-work flow with proper Section 143 handling and GSTR reconciliation.
• Payroll for karigars based on chits and machine production.
• GST invoicing through Tally integration and the IRP.
• Reports for the owner that are about textile, not about accounting.

It runs alongside Schiffli ERP, which is the production-floor system for embroidery and lace manufacturing specifically. Both have been live with paying users for over a year.

The two-product structure is intentional. Schiffli is the workshop-floor product. Paraslace is the order-to-ship product. They share a backbone and an ACL pattern but speak to different roles in the business.

The 18-month decision we're glad we made

Early on, we considered two paths.

Path A: ship a textile module on top of an existing ERP. Fast, less risk, smaller team requirement.

Path B: spend a year and a half building a vertical product that actually fits textile, with a real ACL underneath, on a real Odoo backbone.

We picked B. The cost was eighteen months of being patient while paying competitors shipped flashier-looking products. The benefit is that everything Paraslace does, it does in textile language with textile semantics. We're not asking a karigar to log into "Sales Order Module 3.2". We're asking them to update a chit.

The result is software the floor uses without complaint. That's a low bar nobody we know of has actually cleared.

The cross-vertical lesson

The reason this matters beyond textile: every vertical we plan to build (leather, jewelry, food) has its own version of the same problems. Their own units that aren't standardised. Their own job-work-like flows. Their own GST quirks. Their own paper artefacts.

The Krypto Forge Platform was designed so the backbone stays the same and the vertical changes. ACL plus product code per vertical. Each vertical takes months, not years, because the bones are already there.

Textile was the first because it was where we lived. Leather and jewelry are next because their patterns rhyme with textile, but their vocabulary is their own.

The takeaway

A 200-year-old industry doesn't get automated by importing tech industry assumptions. It gets automated by sitting in it for long enough to know which assumptions don't apply, then building software that respects the industry's actual structure.

AI in 2026 finally makes some of the hard parts (unstructured chits, voice notes, photo matching) tractable, but it doesn't change the fundamental work, which is paying attention.

We sat in a textile factory for eighteen months and then shipped. The product is still being shaped by what we keep learning on the floor.

The shortcut to good vertical software is taking the long way around.