This article is currently available in English while its HI translation is prepared or reviewed.
Most Kenyan SMBs should not build custom software. Spreadsheets, WhatsApp, M-Pesa statements and a handful of affordable SaaS tools genuinely cover most early-stage operations well. This article is about the specific, concrete point where that stops being true, and how to tell whether you have reached it.
Start with what you have
If your team is under 10 people and your process is simple enough to explain in two sentences, a generic tool is almost always the right call. Custom software has a real cost in time, money and your own attention during scoping, and it should be justified by a workflow that is genuinely distinctive, not by ambition alone.
Before considering a build, get the most out of what you already pay for. Many problems blamed on tools are really unclear processes: nobody owns a record, two people update the same sheet, or a step depends on someone remembering. Fixing those habits is cheaper than any software.
The signals worth watching for
- You keep the same data in two or three places, such as a spreadsheet, a SaaS tool and someone's memory, and they disagree.
- A specific compliance, renewal or regulatory requirement does not map to any generic module.
- Your team spends real hours every week on manual data entry or reconciling one tool against another.
- You have hired someone whose main job is "keeping the spreadsheet correct".
- Customers or managers regularly ask for a status nobody can give without phoning around.
- A generic platform's customisation options cover the part of your workflow that matters least.
One signal on its own is rarely enough. Three or four together, especially when they cost you hours or customers every week, are worth a closer look.
Consider the options in order
When the signals add up, work through the options from cheapest to most involved:
- Fix the process. Assign owners, standardise records and remove duplicate steps.
- Configure what you have. Many tools have workflow, automation or integration features that go unused.
- Connect existing tools. An integration that moves data between two systems can remove most of the manual reconciliation without replacing either.
- Build only the distinctive part. Keep standard functions such as accounting in proven products and build the workflow that makes your operation different.
- Build a fuller system. Reserve this for operations where the core workflow is the business and no product fits.
What "worth it" actually looks like
Our Track IQ platform exists because a telematics operator's device renewal and compliance tracking had outgrown spreadsheets. See the Track IQ case study for what that rollout looked like. Cordway Ventures' tourism booking system followed the same pattern: a real operational bottleneck, not a wish for "an app".
In both cases the starting point was a specific workflow that cost time and money every week, a clear owner on the client side, and a first phase small enough to prove its value quickly.
Keep the first phase small
If you do decide to build, start with the smallest version that removes the biggest pain. A first phase measured in weeks, used by real staff and judged against a few agreed measures, tells you far more than a long specification. Extend the system once it has earned its place.
A quick self-check
- Can you describe the problem in numbers: hours, missed renewals, lost jobs?
- Have you tried fixing the process and configuring existing tools?
- Is the workflow you want to build genuinely distinctive to your business?
- Do you have someone who will own the system internally?
- Is there a first phase you could use within a couple of months?
If most answers are yes, a short discovery conversation is a sensible next step. If not, revisit in six months.
Related reading: custom software vs. off-the-shelf platforms and building a business case for custom software. Or talk through your situation →