A POS that works offline — how Kaspa handles patchy connectivity

The fibre line in Colombo drops at least once a week. The power goes for an hour during peak. Mobile data runs out two days before the bill cycle resets. If your POS stops working in any of those moments, you are not running a digital shop — you are running a software project with a side gig in retail.

This post is about how Kaspa handles all of that, and why “works offline” means more than what most POS marketing pages claim.

What most cloud POS systems mean by “offline mode”

Pick a competitor’s marketing page. Almost all of them say “offline mode” somewhere. Read the fine print:

Square: offline payments work for up to 24 hours, card-only, with restrictions on amount and not all sale types.
Loyverse: sales work offline. Adding or editing products requires internet.
Shopify POS: fully online — if your internet drops, the POS stops.
Hike: limited offline; reports and product edits need internet.

The pattern: “offline” means “sales keep going for a bit”. Everything else — the product list, the prices, adding a SKU, fixing a typo, syncing to a second register — needs the network.

For a shop where the internet is rock-solid 99% of the time, this is fine. For a shop in Sri Lanka, India, the Philippines, or rural anywhere, the 1% adds up to several outage windows a month, often during peak hours, often when you most need to change something.

How Kaspa is architected differently

Kaspa is offline-first. That phrase gets thrown around — here is what it actually means in the product.

Every sale completes on the device. When the cashier taps “Pay”, the transaction is committed to local storage immediately. The sale is “done” before the network is even consulted. There is no spinner, no “syncing”, no “please wait while we contact the server”.

Every product edit completes on the device. Adding a new SKU, changing a price, marking a product out of stock, setting up a new cashier — all of these write to local storage first. The internet is informed afterwards, in the background, when it is available.

Sync is a delta operation. When the network returns, Kaspa does not “re-upload everything”. It sends the deltas — the specific changes since the last successful sync — and pulls down deltas from other devices the same way. This means two registers can run in parallel, both offline, both selling the same SKU, and when they reconnect the stock count reconciles correctly. No “last writer wins” data loss. No mysterious overwrites at the end of the day.

The AI assistant degrades gracefully. The conversational AI assistant needs internet to think. When the network is gone, the assistant tells you so plainly — “I am offline, I can answer when we are back online” — and the sell screen, product editor, cashier management, receipt printing, barcode scanning, and reports all keep working. You can do almost everything you need without the assistant; you just lose the conversational layer until the network is back.

Receipts print over USB or Bluetooth, not over the cloud. Some POS systems route receipt printing through their server (so the printer can be remote). Kaspa pairs directly with your 58 / 80 mm thermal printer at the counter. No network round-trip. The receipt prints in the same second the sale completes.

This is not magic. It is a deliberate architectural choice, and it is the reason we are confident telling shop owners “your internet goes down, your sales do not”.

The scenarios that actually matter

Marketing pages talk about offline mode in the abstract. Here are the moments where it counts.

The 6pm CEB power cut

Power drops. The router stops blinking. Your phone is on battery, so it is still alive. A customer walks in. With most cloud POS systems, you have anywhere from “instantly broken” to “broken in 30 minutes” depending on how aggressively the app polls the server.

With Kaspa, the sell screen does not notice. Your phone’s battery is the only constraint. The sale rings up, the receipt prints (your thermal printer probably has a small UPS or runs off the battery pack), and the sync happens whenever the router comes back.

The morning the fibre is dead

You arrive to open the shop. The router has a red light. The ISP says it will be fixed by noon. A delivery just arrived from your supplier — fifteen new SKUs you need to add to the system before you sell them.

In Loyverse, you wait. The app will let you sell what is already in the catalog but adding new products requires server contact.

In Kaspa, you open the assistant — wait, the assistant needs internet too. So you open the product editor directly (the features page covers this) and add the SKUs by hand or paste them in. Sales start when the doors open. The new products sync to the cloud when the fibre comes back.

The remote market stall

You sell at a Sunday market, 40 km outside Colombo. There is no fibre. Mobile data is 3G if you are lucky, edge if you are not.

This is the scenario where most cloud POS systems give up entirely. You either resort to a calculator and a notebook for the day, or you tether to a phone and pray the data holds.

With Kaspa, the data plan is optional. The POS runs from local storage. At end of day, when you get back somewhere with WiFi, the sales sync. Until then, the customer in front of you does not know or care whether you are connected.

The two-register lunch rush

You have a counter and a second register for a takeaway window. Lunch is a hundred sales in two hours. Halfway through, the WiFi router restarts and goes off for ten minutes.

In a POS that needs the server to share inventory between devices, that ten-minute window means the two registers can sell the same item to two customers without realising. End of day, your stock is wrong.

In Kaspa, both registers keep selling. Each commits sales locally. When the WiFi returns, the deltas reconcile — stock counts merge correctly, and any conflicts (rare, because most products do not have one-unit stock) are flagged for review.

”What about syncing?”

The honest answer: sync happens whenever it can. There is no “Sync Now” button. You do not need to remember.

When the device has a network connection, Kaspa exchanges deltas with the cloud every few seconds when there is activity, and at a slower idle rate when there is not. If the device has been offline for a day, the next time it sees the network, it catches up — usually in well under a second. If it has been offline for a week, it still catches up; it is just a bigger delta.

The cloud is the source of truth across devices, not for individual devices. Each device’s local storage is the source of truth for that device until sync happens. This is the same model used by note apps like Bear, by git, and by many financial systems built for high-latency environments. It is well-trodden ground.

”Will I lose data if the device dies offline?”

If your phone falls into a pail of water at 4pm with three hours of unsynced sales on it, you do lose those sales. The same is true of any local-first system. Mitigation:

Run two devices. If both registers are open during the lunch rush, sales from device A sync to device B through the cloud as soon as either of them has a network connection. The probability of both phones dying at the same moment is essentially zero.
Sync once a day, at minimum. Even if WiFi is spotty, opening the assistant on a mobile hotspot for thirty seconds at end of day is enough.
Print receipts. Every printed receipt is a paper backup of the sale. End of day, the cash count and the receipt stack should match.

For 99% of shops the local-first model is more reliable than a “needs internet to commit” model, because the internet drops a lot more often than a phone falls in water.

The customer experience

The reason this all matters is the customer at the counter. They do not want to know whether your POS is local-first or cloud-first. They want to be served in three seconds and walk out with their groceries.

Kaspa’s sell screen takes about three seconds to ring up a single-item sale, online or offline. There is no difference in the experience. The cashier does not see a “we are offline” banner. The customer does not see a delay. The receipt prints. The next customer steps up.

That is the point.

Where this is going

Offline-first is one of the half-dozen things we obsess over. Two more we are working on:

Background reconciliation reports. “Here is what synced from device B today, here is what conflicted, here is what was resolved.” Most owners do not need this, but for two-register shops it is useful peace of mind.
Local-only backup export. A pure-local export of your data that you can save to a USB stick or another device, for owners who want a backup that does not depend on our cloud.

If offline reliability is the reason you have been hesitant to digitise the shop, the answer is: try Kaspa for an afternoon. Open pos.trykaspa.com, sign in with your phone number, add a couple of products, and then turn off your WiFi. Try selling, editing, returning, scanning. Then turn the WiFi back on and watch it sync.

If that is not the experience, tell us. We want to know.

The pitch in one line

Your internet will go down. Your sales should not. That is the design.

Open pos.trykaspa.com and try it. The free tier covers everything in this post. See pricing for the line items.