A point-of-sale system records what happens at the counter and produces the numbers you reconcile against at the end of the day. In Kenya the constraint that matters most is handling cash and M-Pesa in the same till without either being guessed at. Here is what POS costs in 2026 across the realistic options, the two questions worth asking any vendor, and how the trade between a subscription and a build works out over time.
Your three options
| Option | Cost (KES) | The trade |
|---|---|---|
| Cloud POS, subscription | 2,000 to 10,000 per till, monthly | Fast to start, limited to how the vendor built it |
| Licensed software, one-off | 30,000 to 150,000 upfront | You own it, but updates can lag |
| Custom build | 80,000 to 250,000+ | Fits your workflow and carries no per-till fee; larger upfront cost, and you carry the maintenance |
These are planning figures for a first budget. Hardware is separate: a tablet or laptop, a receipt printer at roughly KES 8,000 to 20,000, and optionally a cash drawer and scanner. Many small shops start on a tablet alone, and hardware can be added later. A workflow the software was not built to support is much harder to add later.
The M-Pesa test
This is a common weakness in POS systems designed for card-first markets. Where the system cannot record an M-Pesa sale as M-Pesa, verified against the transaction rather than typed in by a cashier, the daily split depends on cashier accuracy and reconciliation becomes an estimate rather than a check.
Ask for a demo of exactly this: a sale paid by M-Pesa, from the till prompt through to the daily report, with the transaction verified along the way. Watch whether the cashier has to type anything the system could have confirmed for itself. Every keystroke there is a place where the numbers drift.
The offline test
Where the connection is unreliable, a till that cannot record a sale offline will stop the queue when the connection drops. Ask what happens to a sale rung up while offline, and specifically what happens when two branches reconnect at once having both sold the last of an item. A complete answer describes a queue that replays in order and a defined rule for resolving the conflict. If the answer is vague, ask to see it demonstrated.
A worked comparison
An illustrative example, not a quotation. Suppose you run two tills. Compare a cloud subscription at KES 6,000 per till per month against a custom build at KES 180,000:
| Cloud POS | Custom build | |
|---|---|---|
| Upfront | 0 | 180,000 |
| Monthly, two tills | 12,000 | 1,500 (hosting) |
| Year 1 total | 144,000 | 198,000 |
| Year 2 cumulative | 288,000 | 216,000 |
| Year 3 cumulative | 432,000 | 234,000 |
| Adding a third till | +6,000 monthly | One-off, usually small |
On these figures the crossover lands in year two, and it moves earlier with each additional till, because the subscription scales per till while the build does not. That is the trade. At one till, a subscription is usually the lower-cost and lower-risk option; as till count rises, the arithmetic moves toward a build. Where your own crossover falls depends on the per-till rate you are quoted and how long you expect to run the system, so work it through with your numbers rather than these.
Hardware, and what you can skip
Hardware is where a POS budget inflates fastest, usually on things a small shop does not need in month one. What earns its place, and what can wait:
| Item | Rough cost (KES) | Buy now? |
|---|---|---|
| Tablet or laptop for the till | 20,000 to 45,000 | Yes. This is the till |
| Receipt printer | 8,000 to 20,000 | Yes, if customers expect a receipt |
| Barcode scanner | 4,000 to 12,000 | Only if you have barcoded stock and real queues |
| Cash drawer | 6,000 to 15,000 | Only if you take a lot of cash |
| Backup power for the till | varies | Yes if outages are normal where you are |
A phone or tablet plus a printer runs a small shop. A scanner earns its cost where the catalogue is barcoded and queues are long, and not before that. Power is the item most often overlooked: where sales are not written locally, an outage can lose every transaction since the last sync.
Moving off your current system
Switching tills is the part that worries owners most, and reasonably so, because it happens while the shop is trading. The work is mostly preparation rather than technology:
- Do a full stock count first. Migrating an inaccurate count carries the inaccuracy into the new system.
- Export your product list, prices, and supplier details from the old system while you still have access to it.
- Cut over on your quietest day, not the first of the month, and keep the old system readable for a while.
- Run both for two or three days if you can, and compare the daily totals. That comparison is the only real proof the new one is right.
- Train the cashiers before cutover, not on the morning of it.
Other things that matter
- Inventory sync: stock should decrement with each sale and warn you before you run out, not after.
- Multi-branch: if you have or plan more than one location, you want one shared stock count and combined reporting.
- Training time: how long a new cashier takes to become confident is a real operating cost, so test it with somebody who has not seen the system before.
- Your data: ask how you would get your sales history out if you left. If the answer is awkward, factor that in now.
What a POS will not fix
Worth saying plainly, because a new till gets bought to solve problems it cannot touch. A POS records what happened at the counter accurately. It does not change what happens there.
- Stock loss. Better records make it visible sooner, which is useful. Visibility is not prevention.
- Bad buying. The system will show you that a line has not moved in four months. Acting on that is still your job.
- Staff who work around it. If ringing a sale properly is slower than not doing it, some sales will not be rung properly. That is a process and training problem, and it is the most common reason a good system produces bad numbers.
- Cash discipline. A drawer that is short is short whether or not the software knows.
Where a POS earns its money is the hour a day somebody currently spends reconstructing the day from receipts and M-Pesa messages, and the ordering decisions you can finally make from real numbers instead of memory.
The question to ask yourself first
What decision would you make differently if you had accurate daily numbers? If the answer is none, a cheaper till will do. If the answer is that you would reorder differently, staff differently, or drop a product line, then the reporting is what you are buying and the hardware follows from it.
Planning a similar project?
We can help define the requirements, implementation options, and an appropriate project scope. There is more detail on pos systems if that is the closest fit.
Start a project