The realities of building software for Kenyan SMEs

Software that works in a demo and fails in a shop in Nakuru usually failed for reasons that were visible from the start. A few of them, from the perspective of the people who will use the system.

Money moves on phones

M-Pesa is not a payment option; it is the default. A system that treats it as an afterthought — or makes staff re-type transaction codes — will be worked around within a week. Payments, receipts and reconciliation have to be designed around mobile money from day one.

The connection will drop

Design for the moment the internet goes: can the till keep selling, can the field officer keep capturing, and does everything sync cleanly afterwards without duplicates? Offline tolerance is a requirement, not a feature.

Statutory rules are part of the spec

Payroll deductions, tax-compliant receipts and reporting formats change, and businesses are held to them. Build the rules as configuration that can be updated, not constants buried in code.

The spreadsheet already works

Whatever the business uses today is the competition, and it has one advantage: everyone knows it. New software wins by removing a real pain — a stock count that takes a day, a month-end that takes a week — and by respecting the vocabulary and habits people already have.

Support is local, or it is not support

A system used at 7 a.m. on a Saturday needs help available at 7 a.m. on a Saturday. Training, documentation in plain language and a named person to call are as much a part of the product as the code.