Why an Offline POS Is the Only Kind Worth Buying in Kenya

It’s a Saturday evening on Jogoo Road in Nairobi. The queue at the counter is four deep, kickoff is in twenty minutes, and everyone wants to pay and go. At 7:40 the power drops. The router blinks out, mobile data crawls to nothing, and the tablet at the till shows a spinning wheel where the checkout used to be. The cashier taps the screen. Nothing. She apologises to the first customer, then to the second, and one by one the queue drifts across the road to the shop where the till never stopped working.

Same street, same blackout, two very different evenings. The shop that kept selling was not luckier. Its POS keeps everything it needs on the device itself, so it never asked the network for permission to ring up a sale. That design has a name, offline-first, and in Kenya it is the first thing to check before you pay a single shilling for a point of sale. This guide explains what the term actually means, what it changes on an ordinary trading day, and how to test any system yourself in five minutes, no technical knowledge required.

Plenty of vendors say their system “works offline”. Most of them mean it survives a short drop: a cached price list, a few minutes of grace, then error messages. Offline-first is something else. It means the copy of your data that matters lives on your device. Products, prices, staff PINs, the day’s sales: all of it is written to the phone or tablet first, the instant it happens. The internet comes in afterwards, to back that data up and to share it with your other devices. It never stands between the customer and the receipt.

A useful way to hear the difference is to ask where a sale is born. On a cloud-only till, the sale is created on a server far away, and your screen is just a window onto it; cut the connection and the window shows nothing. On an offline-first till, the sale is created in your hand and travels to the server later, whenever the network allows. One model treats connectivity as a requirement. The other treats it as a convenience. In a country where neither power nor data is guaranteed on any given day, only one of those models deserves your money.

The grid dips without warning. A downpour takes out the mast on the hill. Upcountry, the signal fades to one flickering bar by mid-afternoon and sometimes disappears until evening. None of this surprises anyone who runs a shop here, and none of it will be fixed by next year. The only real question is whether your till was built for this reality or for a showroom with fibre.

When the checkout cannot ring up a sale, your shop is closed. The door is open, the shelves are full, the customer is standing there with money in hand, and none of it counts, because the one machine that turns stock into cash has stopped. Nobody waits ten minutes for a network to come back. They cross the road.

Do the arithmetic once and it stays with you. If outages cost you even five or six sales a week, that is real money gone by the end of the month, quietly, with no line in any report to show for it. The sales an offline till saves you during blackouts typically cover its cost many times over. Trading through interruptions is not a bonus feature. In this market, it is the feature.

The benefit people notice second is speed. A cloud till is only as quick as the slowest hop between your counter and a server that may sit on another continent. Every scan waits for a round trip, and on a busy evening the lag stacks up. An offline-first till reads its prices from the device and answers the instant you touch it, whether you have five bars or none.

At a crowded counter that speed is money: shorter queues, more customers served in the same rush, and staff who trust the tool instead of reaching for a notebook every time the screen hesitates.

This is the fear that stops many owners, and it points the wrong way round. People worry that a sale made offline might vanish. In a properly built system, the opposite is true: the sale is written to the device’s storage the moment the cashier completes it, and it stays there until the server has confirmed receipt. Kill the power, close the app, restart the phone; the transactions are still sitting in the queue when you come back.

The device becomes your first and most reliable record, and the cloud becomes the backup. Compare that with an online-only till, where a connection dropping at the wrong second can leave a sale half-recorded and nobody sure whether it went through. When you talk to a vendor, ask exactly how offline sales are stored and when they get marked as synced. A good answer describes a queue on the device that survives restarts. A vague answer is a warning.

There is a smaller saving that repeats every month. An online-only POS chats with its server constantly: every lookup, every sale, every refresh burns airtime. An offline-first system only touches the network to sync, in small batched uploads whenever the connection happens to be good. In practice you can run the till on a modest bundle, or on the evening Wi-Fi at home, and it behaves exactly the same on a cheap prepaid line as it would on fibre. For a shop counting every shilling, a few hundred bob saved on bundles each month is not nothing.

The further you get from the city centre, the stronger the case becomes. A trader at a Gikomba-style market cannot pause a sale to hunt for signal; the pace is too quick and the queue too impatient. A duka in a rural trading centre might see decent coverage for two hours a day. An offline-first POS on an ordinary Android phone fits that world: no fixed line, no router, nothing bolted to a wall. You set it up once, sell wherever you are, and the data syncs whenever you next pass through coverage or reach home Wi-Fi in the evening. This is what finally makes a proper till realistic for the majority of Kenyan traders, not just the supermarkets in the malls.

The right answer is: nothing you have to think about. A well-built system watches for the connection in the background, and the moment it returns, the queued sales upload on their own. No button to remember, no export file, no re-typing at the end of a long day. Everything you rang up during the blackout appears in your reports and on your other devices as if the outage had never happened. If you run two tills, they fall back into agreement by themselves.

Confirm this part specifically before you buy. A sync you must trigger by hand every night is a sync that will be forgotten on exactly the wrong night.

Most Kenyan shops now take money two main ways: cash, and M-Pesa through a Till or Buy Goods number. At closing time the numbers have to agree. The cash in the drawer plus the M-Pesa on your statement should match what the till says you sold, and a POS that lumps everything into one total turns that check into a nightly guessing game.

A good till records each payment method as its own line, offline sales included. digabloPos, to take the example I know best, shows M-Pesa and cash separately in its daily report, so the evening check takes two minutes: count the drawer, open the statement, compare. A shortfall shows up the same evening instead of hiding inside a month of mixed totals. Whatever system you pick, refuse one that cannot split payment methods cleanly.

A receipt is part of the sale. Customers expect one, and so does KRA: under eTIMS, the tax authority’s electronic invoicing system, sales are supposed to be captured and transmitted electronically. The catch with some cloud tills is that the receipt is generated on the server, so no internet means no printout and an awkward pause in front of a full queue.

An offline-first POS builds the receipt on the device and sends it straight to the printer over Bluetooth or USB, no round trip required. The sale is captured on the spot, the customer walks away with paper in hand, and the eTIMS transmission joins the sync queue to go out once the network is back. Your obligations do not pause because the mast went down; a good system makes sure your compliance does not either.

Here is the part vendors of cloud-only systems rarely say out loud. If completing a sale requires the internet, you have handed the keys of your shop to your data provider’s worst day. When the link drops, staff stop trusting the screen and go back to scribbling in a notebook, which someone then re-enters later, badly. Reports drift out of date. A good Saturday turns into an evening of reconstruction. None of that is your team’s fault; it was baked into the design the day you signed up.

The cloud itself is not the villain here. Backups, multi-device sync and checking your figures from home are genuinely useful. The problem is which part was made to depend on the connection.

To be fair, there are places where an always-online till causes no pain: a unit inside a mall with backup power and two internet lines, for instance. If your power and data genuinely never fail, the difference shrinks. So ask yourself how often yours actually do. If the answer is anything other than never, you already know which kind of till to buy.

Never take the word “offline” on trust, because half the systems that claim it only half deliver. The test costs nothing. During the demo, put the device in flight mode, or switch off Wi-Fi and mobile data, and run a complete sale from start to finish. Add products. Take a payment. Print the receipt. Then reconnect and watch whether the sale uploads by itself.

While you are at it, ask the vendor these questions and listen for specifics. Where are my products and prices stored: on the device, or only on your server? If the internet is off for three hours on a Saturday, can I sell the whole time? When the connection returns, do my sales upload automatically, or do I have to do something? Can I print a receipt while fully offline? If two tills work offline at the same time, do they agree once they reconnect?

Confident, concrete answers are a good sign. Vague reassurance, or a demo that only runs on the showroom Wi-Fi, tells you everything you need to know.

Offline-first does not mean the internet is useless. A few jobs genuinely need it: syncing between devices, backing your data up off-site, sending eTIMS receipts to KRA, downloading updates, and letting you check the day’s figures from your sofa. Notice what all of those have in common: none of them blocks the customer standing at your counter. The connection keeps your records complete and shared; the device makes the sale. When the signal is there, the system uses it. When it is not, the counter carries on and everything catches up later. That division of labour is the entire point.

The setup that fits Kenyan conditions is modest. An ordinary Android phone or tablet, quite possibly the one already in your pocket. A small Bluetooth or USB thermal printer, which trades for somewhere around KES 4,000 to 8,000 depending on the model. A barcode scanner only if you sell packaged goods in volume. That is the whole list, and you should be suspicious of anyone insisting you need their proprietary terminal on a monthly hardware fee.

On the software side, start free and prove the tool before spending anything. digabloPos costs nothing to begin with, runs offline-first on that same Android device, splits M-Pesa from cash, and gives each cashier a PIN so you know who rang up what. Load your fifty fastest-selling products, run it alongside your current routine for a week, and pull the plug on the Wi-Fi at least once to watch it shrug. Then decide. The till you want is the one that never noticed the network was gone.