DEV Community: VyaparNext

One Catalogue, Two Channels: How We Think About Sharing Stock Between the Counter and the Website

VyaparNext — Tue, 27 Oct 2026 05:50:20 +0000

A garment shop in Surat has one maroon kurti left in size M. At 7:40 pm a customer at the counter picks it up. At 7:41 pm someone on the shop's website orders the same kurti, same size, same colour. (This is a composite example, not a real shop.)

If the counter and the website keep separate stock counts, both sales go through. Someone has to phone the online customer the next morning and apologise. Do that a few times during Diwali and people stop trusting the website.

We build VyaparNext by Smart Byte Labs, garment shop billing software made in Surat. This post isn't a tour of our code. It's how we think about one catalogue serving two channels, and the questions we'd ask of any system that claims to do it.

Two shops, one shelf

Most shops that go online start with two systems: billing software at the counter and a separate e-commerce site. Each has its own product list and its own stock count. Someone reconciles them by hand, usually late at night, usually from memory.

The idea behind sharing stock is simple to say: there is one shelf, so there should be one stock count. A sale at the counter and an order on the website should both draw from the same number for that exact size and colour.

It's harder than it sounds, for three reasons.

1. The catalogue has to be the same catalogue

Sharing stock only works if both channels agree on what a "thing" is. In the previous post in this series we argued that stock lives on the variant (one size in one colour), never on the design.

That matters twice as much here. If the website sells "Kurti A, M, Maroon" and the counter scans a barcode that means "Kurti A (assorted)", there's nothing to share. The two channels have to point at the same variant rows, with the same sizes, colours and barcodes.

A rough way to picture it (illustrative only, not VyaparNext's schema):

// Illustrative only: a way to think about it, not our code.
type Variant = {
  sku: string;        // "KURTI-A-M-MAROON"
  size: string;       // "M"
  colour: string;     // "Maroon"
  barcode: string;    // printed on the tag
  stock: number;      // ONE number, used by both channels
};

type StockMovement = {
  sku: string;
  qty: number;        // -1 for a sale, +n for a purchase or return
  channel: "counter" | "website";
  reference: string;  // bill number or order number
};

Both channels write movements against the same variant. Neither one owns the stock.

2. Movements beat overwrites

The easy way to "sync" is to copy a number: the counter says M maroon is 3, so set the website to 3. That breaks the moment both sides sell between copies. One sale quietly overwrites the other and stock comes out wrong.

We think about stock as a history of movements instead. A purchase adds pieces, a bill removes one, a website order removes one, a return adds one back. The current count is the result of all of them. When two channels sell close together, both movements are kept, so the count stays honest even if it goes to zero (or briefly below it, which tells you exactly which sale needs attention).

The same thinking runs through VyaparNext's Cloud Sync for counters: stock is recalculated from sales and purchases across devices rather than copied blindly, and when the same product is edited on two devices, the conflict is flagged so a person chooses what to keep.

3. The counter can go offline. The website can't wait.

A garment shop counter has to keep billing when the internet drops. That's the whole point of offline billing software with cloud backup. But a website keeps taking orders all night, whether the counter is online or not.

So there's always a window where the two channels can't see each other. Good design admits that window instead of pretending it doesn't exist. The questions we keep asking:

What happens to the last piece? For fast-moving sizes, some shops keep a small buffer off the website during the festive rush, so the last one or two pieces are sold at the counter only. It's a business choice, not a technical one, but the system should make it easy.
Who gets told when both sides sold the last piece? A clear list of oversold orders beats a stock count that silently goes negative.
Does the counter catch up on its own? When the connection comes back, bills made offline should flow in as movements, not as a pile of numbers to type in again.

We'd rather be plain about this than promise "instant" anything. Sync takes time, and a shop owner who knows how long it takes can plan around it.

Where VyaparNext's plans fit

This is how it maps to what we sell today, from the live pricing page:

POS Lite is free to start on one counter. Billing, purchases and stock stay on that device, and there's no automatic cloud sync.
Cloud Sync (₹299/month + GST) keeps counters in step about every hour.
Store (₹25,000 setup + GST, then ₹1,200/month + GST) is a managed online store. It doesn't include the counter POS.
Commerce (₹35,000 setup + GST, then ₹1,800/month + GST) is the plan where the counter and the website share inventory, orders and customers. A sale at the counter and an order on the website draw from the same stock.

If a shop only needs the counter for now, POS Lite is enough. The shared-stock question only starts to matter once a website is actually selling the same pieces.

Three questions to ask any "one stock" system

Whether you're building this or choosing a POS software for garment shops:

Do the counter and the website sell the same variant rows, down to size and colour?
Is stock kept as movements (sales, purchases, returns) or copied as a number?
What happens, and who is told, when both channels sell the last piece?

Start free with POS Lite on one counter, or book a free demo on WhatsApp: +91 8160356061. More at vyaparnext.com.

Previously in this series: Modelling Clothing Variants: Why a Kurti Isn't One Product.

Modelling Clothing Variants: Why a Kurti Isn't One Product

VyaparNext — Tue, 20 Oct 2026 05:58:00 +0000

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.

Offline-First Billing: How We Think About a Retail Counter That Survives the Cloud Blinking

VyaparNext — Tue, 13 Oct 2026 05:56:09 +0000

On 15 September 2026, Shopify merchants were locked out of their admin for about four hours. StatusGator's write-up puts first reports at 09:14 UTC and the last around 13:26 UTC (roughly 2:45 pm to 7 pm IST). Storefronts mostly stayed up; the back office didn't. Every cloud platform has days like that.

We build VyaparNext, a counter-first POS for Indian clothing shops (Smart Byte Labs, Surat). This isn't a stack deep-dive. It's how we think about one design question that outage raises for anyone building retail software: when the network goes, which tasks still have to work?

"Works offline" is a per-task property

As Posnic points out, offline isn't one switch. So we think about it task by task:

Task at the counter	Needs network on the counter device?
Scan a size/colour barcode and make the bill	No
Print the tax invoice on a thermal printer	No
Update stock on a sale or purchase	No
Record payment as cash or Google Pay/PhonePe	No
The customer's own UPI app completing the payment	Yes, on their phone
Sync with other devices	Yes (Cloud Sync, about hourly)

That UPI row is the one people forget. POS Lite can record a Google Pay or PhonePe payment without Wi-Fi, but the customer's UPI app still needs network. If the whole market is down, keep a cash fallback.

The principles we hold ourselves to

The counter device owns the bill. A sale is made and recorded on the device. Nothing in the billing path waits for a server.
Sync helps; it never gates billing. Cloud Sync (₹299/month + GST) runs about hourly across devices, recalculates stock, keeps seven daily snapshots (India time), and lets a new device load the shop's data.
Paying less should degrade features, not break the counter. If Cloud Sync is cancelled, POS Lite keeps working on each device.
One catalogue going upward. On the Commerce plan, the counter and the online store share inventory, orders and customers, so the website reads the same stock count rather than a nightly copy.

The hard part: the hour after reconnecting

BC4 says retailers often lose money "not during the outage itself, but in the hour after it ends." Two devices can change the same thing while apart.

Our approach: when Cloud Sync runs, it recalculates stock and flags a conflict when the same product was edited on two devices, so a person decides instead of the software silently picking a winner. Because sync is about hourly, not instant, a shop running two counters should still keep an eye on fast-moving pieces on peak nights.

At closing, the end-of-day report shows totals, top items and a staff breakdown, which turns "yeh UPI kiska tha?" into a quick match against the drawer and the UPI app.

The cost ladder, and what it says about the design

From vyaparnext.com/pricing (checked 12 Oct 2026):

Plan	Setup	Monthly
POS Lite	Free to start	₹0
Cloud Sync (add-on)	—	₹299 + GST
Connected POS	₹10,000 + GST	₹600 + GST
Store	₹25,000 + GST	₹1,200 + GST
Commerce	₹35,000 + GST	₹1,800 + GST

For shops that run their own server, there is also a Connected POS option at ₹450/month + GST.

The rule behind the ladder: the free tier must be a complete offline counter, and each paid step adds sync or a storefront, never the ability to bill.

Try the ten-minute test

Turn off Wi-Fi and data on the billing device. Make a bill, print it, check stock. Turn the network back on and see what catches up by itself and what gets flagged. It tells you more than any spec sheet, including ours.

More at vyaparnext.com. Previously in this series: ₹1,499 Is Only the First Line.

₹1,499 Is Only the First Line: The Real Cost of Shopify for an Indian Fashion Store

VyaparNext — Sun, 11 Oct 2026 09:59:06 +0000

Kavita ben and her shop are a composite of women's wear shop owners we have met in Gujarat. Names and details are changed. The numbers come from public price pages, checked in October 2026.

Kavita ben runs a kurti and dress material shop in Rajkot. Twelve years at the same counter, and a WhatsApp broadcast list that sells half her new stock before it reaches the shelf.

This year her son Harsh said what every son says: "Mummy, we need a proper website." He opened Shopify's India pricing page, saw â‚¹1,499 a month, and said, "That's less than the electricity bill."

He was right about the first line. The trouble is that a store's bill has more than one line.

The number on the pricing page

Shopify's India pricing page is clear. Basic is â‚¹1,499 a month when you pay yearly, or â‚¹1,994 when you pay month to month. Grow is â‚¹5,599 a month yearly (â‚¹7,447 monthly), and Advanced is â‚¹22,680 a month yearly (â‚¹30,164 monthly). There is also an offer for new stores of three days free, then â‚¹20 a month for three months.

For hosting, checkout and a polished admin, that is fair pricing. But for an Indian fashion store, it is the start of the bill, not the end.

The line most people miss: the third-party fee

Shopify Payments, Shopify's built-in payment processing, is not available in India. India is not on Shopify's list of supported countries, so an Indian store has to use a third-party payment gateway.

When you do that, Shopify adds its own third-party transaction fee: 2% on Basic, 1% on Grow and 0.6% on Advanced. That is on top of what the gateway charges. A typical Indian gateway's standard rate is about 2% per successful transaction, plus 18% GST on that fee.

Here is a simple illustration. Say Harsh's website sells â‚¹2,00,000 a month on the Basic plan:

Shopify's third-party fee at 2%: â‚¹4,000
A gateway's fee at about 2%: â‚¹4,000, plus â‚¹720 GST on that fee

That is close to â‚¹8,700 a month in payment-related charges, already more than five times the plan fee. Grow cuts Shopify's share to 1%, but the plan costs more, so do the sum for your own shop.

What about the 2026 Shopify Payments fee changes you may have read about? They mostly concern merchants who can use Shopify Payments. Reports describe a standardisation of older rates for some long-time US and Australian merchants from April, and a change from 6 April 2026 in how currency conversion fees are calculated. Parity, which tracks these rates, says standard US processing rates did not go up in 2026. For an Indian store, the line that matters is still the third-party fee.

The apps a fashion store ends up needing

Shopify keeps its core lean and lets apps fill the gaps. For a kurti shop, the gaps add up fast, and most apps are billed in US dollars every 30 days. Here is what we found on the Shopify App Store this month, with one example app for each job.

More options than size, colour and fabric. Shopify allows three options per product. For a fourth, like fit or sleeve length, its own help centre points to an app. Globo Product Options has a free plan, and its add-on pricing starts at $9.90 a month. Infinite Options is $12.99 a month.
GST invoices. Apps like GST Invoices India and GST Pro are free for up to 50 orders a month. Paid plans start at about $4.99 to $9.90 a month and go up with order volume.
Reviews. Judge.me has a generous free plan. Its paid plan is $15 a month.
WhatsApp order updates. For an Indian shop, this matters more than email. Apps start at about $3 to $5 a month, plus per-message charges as volume grows.
The theme. Shopify's own themes are free. Paid themes in the Theme Store are a one-time purchase of about $100 to $500, with a median of about $300.

Pick one paid app for each of the first four jobs and the monthly app bill comes to roughly $30 to $45, before any message charges. None is outrageous alone. Together, they are a second subscription that grows as you grow.

The counter is a separate question

Then there is the counter, where Kavita ben still makes most of her money.

Shopify's plans include casual in-person selling for pop-ups and events. For a real shop, Shopify sells POS Pro, which adds staff roles, in-store inventory management and pickup. On its India page, POS Pro costs â‚¹7,000 a month per location. That is â‚¹84,000 a year for one shop.

If you skip POS Pro and keep your old billing software, you now have two catalogues. The yellow anarkali in M sells at the counter at 6 pm, and the website still shows it in stock at 9 pm. Someone has to fix that by hand, every night, all through wedding season. We wrote about one family living this problem in One Kurta, 144 Variants.

What one catalogue saves

When Harsh added it all up for one shop on Shopify Basic, paid yearly, with POS Pro, the first year looked like this, before taxes, apps, theme and payment fees:

Basic plan: â‚¹1,499 Ã— 12 = â‚¹17,988
POS Pro, one location: â‚¹7,000 Ã— 12 = â‚¹84,000
Total: about â‚¹1,02,000 a year

That is when he called us.

We are VyaparNext, built by Smart Byte Labs in Surat. Our tagline is "Simple. Affordable. Connected." VyaparNext is a retail POS built for fashion shops first, with a built-in website that shares the same catalogue as the counter.

Variants that fit a fashion catalogue. Size and colour are part of how products are set up, and each variant can have its own barcode. Staff scan the tag and the bill takes that exact variant's price and stock.

Tax invoices and offline billing at the counter. The bill is a tax invoice (one tax rate) and prints on a thermal printer. Billing keeps working when the internet drops. VyaparNext does not file your GST return, so your CA still has a job.

One catalogue for the counter and the website. On the Commerce plan, the counter and the website share inventory, orders and customers. When the yellow anarkali in M sells at 6 pm, the website draws from the same stock count.

Here is what that costs, from vyaparnext.com/pricing (fees in INR, excluding 18% GST):

POS Lite: â‚¹0. Offline billing, purchases, stock and customers.
Cloud Sync: â‚¹299/month + GST. Hourly sync across devices.
Connected POS: â‚¹10,000 + GST setup, then â‚¹600/month + GST. Cloud inventory sync, with a website optional.
Store: â‚¹25,000 + GST setup, then â‚¹1,200/month + GST. A managed online store on your own domain.
Commerce: â‚¹35,000 + GST setup, then â‚¹1,800/month + GST. The counter and the website share inventory, orders and customers.

For Kavita ben's shop, Commerce comes to â‚¹56,600 in the first year (â‚¹35,000 + â‚¹1,800 Ã— 12) and â‚¹21,600 a year after that, before GST. Online payments still carry your payment provider's charges, as they do on any platform, but our pricing page lists no extra per-order platform fee on top of the plan. And you don't have to start there. You can start on free POS Lite at the counter and switch the website on when you are ready.

When Shopify is the right choice

To be fair, Shopify is excellent at what it is built for. If you sell mostly online, ship across India or abroad, and want a huge app ecosystem and a proven checkout, Shopify may well be worth every rupee, especially for brands with a team to manage the apps. And on price alone, Shopify Basic is cheaper in the first year for a shop that only needs a website. VyaparNext earns its place when the counter is the heart of the business.

But if your shop lives at the counter, your catalogue runs in sizes and colours, and your evenings go into matching the register with the website, add up the whole bill before you choose. Look at all of it, not just the first line.

Prices change, on Shopify, on app stores and on ours. Check the live pages before you decide.

VyaparNext is built by Smart Byte Labs in Surat. Simple. Affordable. Connected. POS Lite is free to start at vyaparnext.com, and every plan is on vyaparnext.com/pricing. Send us your current monthly Shopify bill on WhatsApp at +91 8160356061, and we will add up both sides with you, honestly.

I'm Pradip Parmar.

I write a short weekly letter for shop owners who sell at the counter and online. It's free at vyaparnext.substack.com.