There is a category of software failure that only shows up on the worst possible day. Billing software that requires a live internet connection is in it.
The failure is simple. The connection drops during a busy hour. The counter stops. A queue forms. Staff start writing on paper, and somebody has to reconcile that paper later, usually incorrectly.
The assumption behind cloud-only POS
Most modern billing products are built cloud-first, and for good reasons: central reporting, no local backups to manage, updates that apply everywhere at once.
The assumption underneath is a reliable connection. In a mall in a major city, that assumption mostly holds. In a shop on the outskirts of a smaller town, in a basement, in a warehouse with thick walls, or in parts of the country where the link drops several times a day, it does not. It also does not hold on the day the local provider has a fault, which is precisely the day you least want to stop trading.
We build offline-first by default for counter software, and it is not a premium feature. It is what makes the software usable.
What offline-first actually means
It does not mean "has an offline mode". It means the local database is the one the counter talks to, always, and syncing is a background concern.
A bill is written locally and is immediately valid. Stock is decremented locally. A receipt prints from local data. When the connection returns, the local records sync to the server and central reporting catches up. The counter never waits for a network round trip, which incidentally also makes it faster on a good connection.
The hard part is not the offline storage. It is deciding what happens when two counters bill the same last unit of stock while both are offline. That needs an explicit answer, designed in -- usually a per-counter stock allocation or an accepted reconciliation step -- rather than discovered in production.
Things that break if you bolt it on later
Offline capability is one of the handful of requirements that is cheap to design in and expensive to retrofit. It shapes the data model, the way identifiers are generated, and how conflicts resolve.
Invoice numbering is the usual casualty. If the server assigns the number, an offline counter cannot produce a compliant invoice. The fix is a per-counter prefix and a local sequence, agreed with your accountant before go-live. Decided afterwards, it means reissuing documents.
The same applies to field software. Delivery proof, site measurements and procurement entries are all captured in places where connectivity cannot be assumed, and all of them get abandoned by the people using them if the app spins waiting for a signal.
What to ask a vendor
Ask what happens when the internet is cut while a bill is open. Ask to see it, with the cable pulled.
If the answer involves waiting, or a message asking the operator to try again, you have learned something important about how that software will behave on your busiest afternoon.