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 Connected POS + Website 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 3 Nov 2026):
| Plan | Setup | Monthly |
|---|---|---|
| POS Lite | Free, ₹0 forever on one counter | ₹0 |
| Cloud Sync (add-on) | — | ₹299 + GST (14-day free trial) |
| Connected POS | — | ₹599 + GST, Cloud Sync included (14-day free trial) |
| Launch Store / Brand Store | ₹25,000 development + GST | ₹1,499 + GST (or ₹14,999/year + GST) |
| Connected POS + Website | ₹25,000 development + GST | ₹1,999 + GST (or ₹19,999/year + GST) |
| Add-on: 1,000 more products | — | ₹199 + GST |
| Add-on: 5 GB more image storage | — | ₹99 + GST |
| Add-on: 100 GB more bandwidth | — | ₹1,299 + GST |
Launch offer: for the first 25 stores, the one-time ₹25,000 development fee still applies, and the monthly charge (₹1,499 for Launch Store / Brand Store, ₹1,999 for Connected POS + Website) is free for year 1.
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 (2)
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.)
The ten-minute test is the best advice in here. Spec sheets never tell you what happens when the router dies mid-bill.
One thing we ran into building offline POS flows in Flutter at Stacklyn Labs: invoice numbering. If two counters bill while apart, one shared running number can't stay unique, so each till needs its own series (a device prefix like C1-0001 and C2-0001). That keeps every number unique without waiting on sync. Under GST the series also has to stay unique within the financial year, so it's worth settling the prefix scheme before the first bill prints rather than after.
Curious how VyaparNext handles this when a new device is loaded from a snapshot: does it get a fresh series, or continue the old device's?