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.
Top comments (1)
Strong write-up. The per-task table is the right frame, and you're right that the reconnect hour is where it actually goes wrong.
One retail-specific trap worth naming: if Cloud Sync reconciles stock by writing an absolute quantity, two counters that each sold the same fast-moving SKU while apart can silently lose one sale on merge (the number last-write-wins, not the movement). Merging movements/deltas instead of absolute counts is what keeps the post-outage hour honest. Same family: a voided bill has to sync as a tombstone, otherwise a device that was offline when it was voided resurrects the line on the next pull.
How do you scope the two-device conflict flag, by product row or by the specific stock movement? Row-level flags seem to get noisy on peak nights, when one counter touches a product for a sale and the other for a purchase.
(If it's useful, I keep a free one-page 8-point self-check for this class of bug: dev.to/alfa_ilands/8-checks-that-c... — the delta-vs-absolute and tombstone items are the two I'd run on a POS counter first. No pitch.)