Most point-of-sale systems are built on one assumption that rarely gets said out loud: the internet is always there. That holds in a downtown cafe. It fails at a motorcycle accessories workshop in Yogyakarta that we work with, where a signal only appears through a hotspot, and only in certain seasons.
For a store owner this is not a technical matter. A stalled register means a waiting line, receipts written by hand, and stock counts that drift away from what is actually on the shelf. This article describes how we designed a register for those conditions, what nearly went wrong along the way, and what you can take from it if your business faces something similar.
Why an Ordinary Offline Mode Is Not Enough
Many POS apps advertise an "offline mode", but what they really offer is a temporary buffer. Transactions are held in the browser and sent once the internet returns. For a store that loses its connection now and then, that works. For a store that is almost never connected, the buffer becomes a source of trouble: data piles up in a single browser, disappears when the browser is cleared, and nobody can say which copy of the data is the real one.
The difference lies in how you look at the absence of internet. In a conventional design, offline is an emergency that is expected to pass quickly. In ours, offline is the normal state, and the internet is the occasional visitor. The three decisions below follow from that shift in perspective.
Three Design Decisions
1. The store PC is the only place transactions are recorded. The cloud version is never used for input. It serves only as a mirror for reports, so the owner can check revenue from a phone without being at the store. With a single source of truth, the question "which data is correct" never comes up. If the two sides differ, the store side wins, because that is where the transaction actually happened.
2. Synchronization runs automatically at intervals, with a manual button as backup. The cashier does not need to remember anything or wait for anything. As soon as a connection exists, data goes out by itself. If the hotspot happens to be on and the owner wants the latest report right then, one button does it. A connection that drops mid-transfer breaks nothing, because the original data stays safe on the store PC.
3. The installation package carries everything. We bundle the application with all of its components, so installing it on site needs no internet at all. It sounds trivial, yet it is often the real obstacle: many systems fail to get installed not because the design is poor, but because the installation itself needs to download hundreds of files from the internet.
We also deliberately chose lightweight technology with no extra layers, because the computer in the store is an older PC with modest specifications. A system that runs smoothly on our laptops but crawls on the store PC is a failed system, however good its features.
How Data Travels From the Store to the Report
The flow is kept simple on purpose, so store owners can follow it, not just engineers. The cashier records a transaction on the store PC. It is saved there immediately, with nothing to wait for. At set intervals, or when the sync button is pressed, the system sends any unsent transactions to the cloud. On the cloud side, the incoming data becomes reports and a summary view for the owner.
What matters is that transaction data moves in one direction only: from the store to the cloud, never the reverse. That simplicity is what makes the system trustworthy, since there are no two sides overwriting each other's data.
The Bug That Only Appears at the Seam
This is the part we learned the most from. While reviewing the synchronization path, we found that transactions arriving from offline mode never reduced stock. For a store that sells parts and accessories, stock that does not decrease is a serious problem, because the number in the system slowly drifts away from reality on the shelf.
The cause was subtle. On the online path, a transaction is created as "pending", then its items are added, then its status changes to "paid". The stock deduction fires on that final change. On the sync path, the transaction was created as "paid" straight away, before its items were added. The system saw a paid transaction with nothing in it, concluded there was nothing to deduct, and marked it done. The order was reversed, and there was not a single error message to show for it.
Each component works correctly when tested on its own. What was wrong was the order between them. We found it through an audit before a single real transaction was affected, then fixed it and retested until the full suite passed.
The lesson applies well beyond registers: the most important tests are not on individual components but on the seams between them, especially on paths that are rarely walked. A rarely used offline path is exactly where a bug like this hides longest.
What We Deliberately Did Not Build Yet
Two-way synchronization for product and price data did not make the first version. For now the rule is simple: products and prices are changed on one side only, never in two places at once. We would rather have a narrow system that can be trusted than a complete one that carries a risk of data mismatch. That feature follows once the foundation has proven itself.
Deciding not to build something is often harder than deciding to build it. Every extra feature in a system that handles money and stock is a new surface where mistakes can get in.
Four Questions Before You Choose a POS System
If your business has less than ideal network conditions, and many stores across Indonesia do, put these four questions to any vendor before signing anything.
- What happens to my store if the internet is down for a full day?
- If there are two copies of the data, which one counts as correct, and who decides?
- Does the system run smoothly on the computer I actually use, not on a demo machine?
- How does stock stay accurate after offline transactions sync?
A good POS system is not measured by its features when everything is normal. It is measured by how it behaves under imperfect conditions. For many stores in Indonesia, imperfect conditions are simply everyday conditions.
How XETUP Can Help
The experience at this workshop shaped how we build POS systems for businesses whose field conditions are not uniform. If your store or branch deals with an unstable connection, or you want to know whether your current register would survive an outage, explore XETUP's products or contact our team to talk it through directly.