Why I’m Building a Textile & Apparel Platform in the Age of AI

YuWang — Wed, 21 Oct 2026 15:01:15 +0000

AI has made it much easier for a solo builder like me to turn an idea into a working website. The question I kept coming back to was: which problems do I understand well enough to build something useful?

For me, the answer was textile and apparel sourcing.

I’m building KeqiaoGuide, a website combining practical sourcing guides, small calculation tools, and supplier site-visit services for apparel businesses.

The interesting part has been translating industry knowledge into software: deciding what can be calculated, what needs verification, and where a tool should stop making assumptions.

1. The Problems Behind the Project

For someone starting a clothing brand, buying fabric involves more decisions than choosing a color and negotiating a price.

A supplier might quote by the kilogram while another quotes by the meter. A sample might look right but behave differently after washing. A factory’s showroom might tell you very little about how it manages production.

Three problems shaped the project:

Comparing quotations: A price per kilogram cannot be compared directly with a price per meter. Fabric weight and width affect the conversion.
Understanding specifications: Buyers need to distinguish GSM from grams per linear meter, full width from usable width, and a soft hand feel from suitable drape.
Checking suppliers remotely: Photographs and sales conversations provide only part of the picture. Assessing production capabilities requires specific questions and supporting evidence.

These are practical information problems with consequences for physical products.

A website can help buyers understand the questions they need to ask, check calculations, and recognize when they need more evidence before placing an order.

2. Turning Industry Knowledge into Useful Features

I organized the project around three complementary parts:

Practical guides explaining fabric properties, quality checks, costing, and supplier assessment.
Interactive tools helping users estimate quantities and prepare sourcing decisions.
On-site services for buyers who need someone to visit a supplier and document agreed details.

Each part has different limits.

An article can explain what to inspect, but it cannot verify a particular factory. A calculator can estimate fabric requirements, but it cannot inspect a cutting marker. A supplier visit can document what was observed, but it cannot guarantee the quality of every future shipment.

Making those boundaries visible has become an important part of the product design.

3. How AI Helped Me Build It

I used AI coding tools to help build the site with Next.js, React, and custom CSS, then deployed it as a static site on Cloudflare Pages.

The calculators run in the browser, so their calculations do not require a backend.

AI helped with implementation, interface revisions, and polishing technical English for international readers. It also made it easier to move between a written explanation and a working interface.

However, I still needed to define what each input meant, verify the calculations, and decide which assumptions users should see.

In textile sourcing, a formula can be mathematically correct while its application is wrong. For example:

Does “width” include unusable selvages?
Has shrinkage already been compensated for in the pattern?
Does a consumption figure already include cutting losses?
Does the entered panel area include every piece required for the garment?

Those questions determine whether the result is useful.

4. Case Study: A Fabric Consumption Calculator

One tool on the site is a Fabric Consumption Calculator for rough budgeting and quotation checks.

It supports simple woven-garment shortcuts, knit estimates based on total pattern-piece area and GSM, and an option to enter an existing per-garment consumption figure.

For the knit estimate, the starting calculation is:

Net fabric weight per garment (kg)
= total pattern-piece area (m²) × GSM ÷ 1,000

For example, a combined panel area of 1 m² at 240 GSM gives a starting weight of 0.24 kg.

The more interesting implementation work involved defining the adjustments.

A 10% Allowance Is Different from a 10% Loss

Suppose an order needs 100 meters before cutting losses.

Adding a 10% allowance gives:

100 × 1.10 = 110 meters

But if 10% of the gross fabric issued will be lost, the calculation is:

100 ÷ 0.90 ≈ 111.11 meters

Both calculations are valid. They answer different questions.

The implementation therefore makes the distinction explicit:

function applyCuttingAllowance(base, rate, basis) {
  return basis === "loss"
    ? base / (1 - rate)
    : base * (1 + rate);
}

Here, rate is a decimal, so 10% is entered as 0.10. The interface validates inputs and asks users which definition they mean.

Defaults Can Hide Assumptions

All allowance inputs start at zero.

That does not mean real production has no losses. It means the tool should not invent a suitable percentage for an order it knows nothing about.

Users can enter measured shrinkage and additional allowances, with reminders to avoid counting adjustments already included in their starting figure.

Width Shrinkage Cannot Always Be Solved by Buying More Length

For area-based weight estimates, the tool can compensate for shrinkage in both directions.

For linear-meter estimates, width shrinkage creates another question: will the pattern pieces still fit within the remaining usable width?

Adding extra length cannot answer that question. The interface explicitly asks users to confirm the marker fits the post-shrink width.

Showing the Limits Is Part of the Feature

The result includes a breakdown and the calculation basis.

It also states that the tool does not generate a cutting marker, determine pattern fit, or calculate plaid matching automatically.

Final consumption still requires approved pattern data, the actual cutting marker, size ratios, and production conditions.

That limitation matters because a precise-looking number can otherwise suggest more certainty than the inputs justify.

5. What I’m Learning

The main challenge has been deciding which parts of a sourcing decision can reasonably become software inputs.

Some information fits neatly into a form: quantity, GSM, measured shrinkage, or quoted price. Other information requires inspection, judgment, or a conversation with the supplier.

I’m also learning to separate different kinds of evidence in the articles:

Published standards and official guidance
Product or supplier specifications
Practical sourcing observations
Illustrative calculations

They serve different purposes, and readers should be able to tell them apart.

The site is still early. My next priority is improving the existing tools and guides based on questions from apparel founders and sourcing buyers.

AI has made building and revising the software more accessible to me. Industry knowledge helps me decide what the software should do—and when it should ask the user to verify something outside the browser.

If you’re building software for a traditional industry, I’d be interested to hear about a domain rule that looked simple until you tried turning it into an interface.

Disclosure: I used AI assistance to edit and organize this article. The project examples and implementation details describe my own website.

DEV Community: YuWang