A shop owner points at a rack and says "that's one kurti." It's one design. It is not one product, at least not to the software at the counter.
Take one straight-cut kurti in five sizes (S to XXL) and three colours. That's 5 × 3 = 15 things the shop can run out of separately. Fifteen stock counts, fifteen tags, fifteen answers to "do you have this in M?" (These are example numbers, not a real shop's catalogue.)
We build VyaparNext, a counter-first POS for Indian clothing shops (VyaparNext by Smart Byte Labs, Surat). This post isn't a schema dump of our code. It's how we think about modelling clothing so that the counter, the stock count and the tag on the garment all agree.
Three layers: design, variant, the thing on the shelf
When we think about a clothing catalogue, it helps to keep three ideas apart:
- The design (the "product"): the kurti as the customer describes it. Name, category, photos, description. Nobody can buy "the design"; they buy one piece of it.
- The options: the axes the design varies along. For our catalogues that means size and colour.
- The variant (often called the SKU): one exact combination, like Kurti A, M, maroon. This is what has a stock count, what gets a barcode tag, and what goes on the bill.
A rough, illustrative shape (not our actual schema):
// Illustrative only: a way to think about it, not VyaparNext's code.
type Design = {
name: string; // "Straight-cut festive kurti"
options: {
size: string[]; // ["S", "M", "L", "XL", "XXL"]
colour: string[]; // ["Maroon", "Mustard", "Teal"]
};
};
type Variant = {
design: Design;
size: string; // "M"
colour: string; // "Maroon"
barcode: string; // printed on the tag
stock: number; // counted per variant, never per design
};
The rule we hold to: stock lives on the variant, never on the design. "We have 40 of Kurti A" is not useful at 8 pm on a festive Saturday. "We have 0 in M maroon and 6 in L maroon" is.
Why "one product with a size field" breaks
The tempting shortcut is one product row with size and colour typed in as free text on the bill. It looks simpler. It fails in predictable ways:
- Stock can't be counted. If the bill says "Kurti A (M, maroon)" as text, the system knows a kurti sold but not which one. The register says maal hai; the shelf says no M.
- Spelling drift. "Maroon", "maroon", "Mehroon" and "Mrn" become four colours. Free text on a busy counter always drifts.
- Reorders go blind. You can't see that M and L sell out while XXL sits, because nobody recorded which size actually left the shop.
Making each size and colour a real variant fixes all three, because there's nothing to type. You pick or scan.
The other mistake: fifteen unrelated products
The opposite shortcut is to create fifteen separate products, "Kurti A M Maroon", "Kurti A L Maroon" and so on. Now stock is right, but the design has disappeared:
- The website can't show one kurti with a size and colour picker.
- Changing the description or photos means editing fifteen rows.
- Reports can't answer "how did Kurti A do this Navratri?" without someone adding them up by hand.
That's why we keep the three layers. The variant carries stock and the barcode; the design keeps the group together.
Barcodes belong to variants
For a clothing counter, the barcode is the variant's identity in the physical world. In VyaparNext, each size and colour can have its own barcode tag. The flow we design around:
- A purchase comes in, and stock goes up for that exact size and colour.
- Tags are printed for those variants before the pieces reach the shelf.
- At the counter, staff scan the tag. The bill picks up that variant, and stock for that exact size and colour goes down.
- The bill prints as a tax invoice (one tax rate) on a thermal printer.
The point of scanning isn't speed alone. It's that the stock decrement happens on the right row without anyone choosing from a dropdown while three customers wait.
Combinations grow fast, so make setup cheap
Variants multiply. Five sizes and three colours is 15; six sizes and eight colours is 48 for one design. Two things keep that manageable:
- Generate, don't type. Define the size list and the colour list once, and let the system create the combinations. Delete the ones the shop doesn't actually stock.
- Bulk import. VyaparNext supports CSV import for products, so a catalogue doesn't have to be keyed in one variant at a time.
It's also worth knowing other platforms' limits before you design a catalogue. Shopify's help centre, for example, says a product can have up to three options and up to 2,048 variants. That's plenty for most catalogues; it's just a number worth knowing up front.
Offline doesn't change the model
A variant-level model has to work when the internet doesn't. On VyaparNext's POS Lite, billing, purchases and stock changes happen on the counter device, so a scan still decrements the right variant with Wi-Fi off. With Cloud Sync, devices sync about every hour, stock is recalculated from sales and purchases across devices, and a conflict is flagged when the same product was edited on two devices, so a person decides rather than the software quietly picking one.
Where this leaves you
If you're building retail software for clothing, or choosing some, three questions tell you most of what you need:
- Does stock live on each size and colour, or on the design?
- Can each size and colour carry its own barcode?
- Does billing decrement that exact variant, even offline?
POS Lite is free to start, and paid steps (Cloud Sync at ₹299/month + GST, then Connected POS, Store and Commerce) are on vyaparnext.com/pricing. More at vyaparnext.com.
Previously in this series: Offline-First Billing: How We Think About a Retail Counter That Survives the Cloud Blinking.
