Custom Software Development in Kenya: When Off-the-Shelf Stops Working

Every growing Kenyan business reaches the same moment. The off-the-shelf system that carried you from ten staff to eighty starts fighting you. Someone maintains a spreadsheet to work around it. A WhatsApp group has quietly become an approval workflow. Two people spend their mornings copying data between two systems that were both sold as complete solutions.

That is the signal. Not that the software is bad, but that your business has become specific enough that generic software now costs more than it saves.

This article is about knowing when that moment has arrived, what custom software development actually involves, and how to buy it without ending up with an expensive system nobody uses.

When off-the-shelf stops working

Packaged software is excellent value when your process is ordinary. It stops working when one of these becomes true.

1. The workarounds have become the process

If your team exports to Excel to do the real work, the software is a data entry form, not a system. Every export is a break in your audit trail and an opportunity for a number to change without explanation.

2. Your differentiator is the thing the software cannot do

If how you price, route, schedule or reconcile is why customers choose you, forcing it into a generic tool means slowly becoming ordinary. The parts of the business that make you money deserve software that matches them.

3. Licence cost scales faster than value

Per-user pricing punishes growth. When you are choosing who gets a licence rather than who needs access, the tool is shaping your org chart.

4. Nothing talks to anything

You have a POS, an accounting package, a spreadsheet for commissions and a WhatsApp group for field updates. Nobody can answer "what did we actually make on that job?" without a two-day investigation.

5. The data exists but the answer does not

Every fact you need is in a system somewhere. Getting them into the same view requires a person, a weekend and a lot of copy-paste.

The honest alternative: configure before you build

At Upeosoft Limited we started as an ERPNext consultancy and extended into custom engineering, in that order and deliberately. It matters because the cheapest custom software is the custom software you do not write.

Before we quote a build, we ask whether the need can be met by:

• Configuring ERPNext - custom fields, workflows, print formats, permission rules and reports cover a surprising amount of "we are different"
• A custom app on top of ERPNext - your logic in a versioned app, using the existing accounting, stock and permission engine rather than rebuilding them
• An integration - two good systems that simply need to talk, rather than one new system to replace both
• A focused custom build - a portal, dashboard, field app or platform where nothing existing fits

Most requests we receive for "a whole new system" are really requests for three reports, one integration and a mobile screen. The discipline is in finding that out before anyone writes code.

Genuine custom builds earn their place when the workflow is your business, when you need to serve customers or partners directly through a portal, when field operations need offline capability, or when you are building a product to sell rather than a tool to run operations.

What custom software development includes

A serious build is more than programming. The full scope looks like this.

Discovery and scoping

Sitting with the people who do the work, mapping the current process, identifying what must change and what must not. The deliverable is a written scope with explicit exclusions. What is not in version one matters as much as what is.

Architecture and data model

The data model is the decision you live with longest. Getting entities, relationships and states right early is far cheaper than migrating them later. This is also where integration points, permissions and audit requirements are designed in rather than bolted on.

Interface design

Business software is used for eight hours a day by people who did not choose it. Screen design for a store clerk entering two hundred lines is a different discipline from a director's dashboard. Both matter.

Build, in reviewable increments

Working software every two to three weeks, in an environment you can log into. If you cannot see progress until the end, you cannot correct course, and course correction is the whole point of building custom.

Integration

Payments, M-Pesa, SMS, WhatsApp, KRA eTIMS, banking, existing ERP or accounting. Most Kenyan business software lives or dies on how well it connects to what already exists.

Testing, deployment and handover

Automated tests where they pay for themselves, user acceptance testing with real scenarios, containerised deployment, monitoring, backups, documentation and a support arrangement. Then training and a supported rollout.

What we build with, and why

Layer	Typical stack	Why
Web front end	Next.js, React, TypeScript	Fast, well-supported, easy to hire for
Mobile	React Native, Flutter	One codebase, offline-first field apps
Backend	Frappe, FastAPI, Django, Python	Frappe when ERP logic is core, FastAPI or Django when it is not
Data	PostgreSQL, MariaDB, Redis	Proven, open, no licence trap
Infrastructure	Docker, Kubernetes, AWS	Reproducible deployments, portable hosting
AI	Anthropic Claude, OpenAI	Applied to specific workflows, not sprinkled on top

Everything in that list is open or standard. If you and Upeosoft ever part ways, you leave with source code you own and a stack any competent team can pick up. That is a deliberate choice.

What it costs to get custom software wrong

Failed custom builds share a small set of causes, and none of them are about the code.

• Scope written by people who do not do the work. The system matches the org chart's imagination, not the warehouse floor.
• Big bang delivery. Nine months of silence, then a launch nobody is ready for.
• Rebuilding accounting from scratch. Ledgers, tax, stock valuation and multi-currency are solved problems. Rebuilding them is how a six-week project becomes a two-year one.
• No owner inside the business. Without someone empowered to make decisions, every question becomes a delay.
• Code you do not own. Check the contract. If you cannot see the repository, you are renting.
• No plan for after launch. Software is a living thing. Budget for its second year.

There is one more, increasingly common: building the AI layer before the operational layer works. If your core data is incomplete or untrusted, an AI assistant will confidently answer with wrong numbers. We covered that pattern in don't get pressured into buying AI before your business is ready.

How to start

Before you brief any developer, do this preparation. It costs you nothing and improves every quotation you receive.

1. Write down the ten things that waste the most time each week. Be specific and name the person and the hours.
2. Follow one transaction end to end and write down every system, form and message it touches.
3. Decide what success looks like numerically. "Order to dispatch under four hours" is buildable. "Better efficiency" is not.
4. Name an internal owner who can make decisions without a committee.
5. Ask candidates what they would not build. Anyone who says yes to everything has not understood the problem.

Talk to us about your build

Upeosoft Limited is a Nairobi-based software firm. We started with ERPNext consultancy and extended into custom engineering, mobile apps, enterprise integrations and AI automation, with over 200 systems delivered. We work across retail and distribution, manufacturing, automotive, real estate, waste management, security services, professional services and finance and lending.

Tell us what your team is working around and we will tell you honestly whether it needs configuration, integration or a genuine custom build. Sometimes the right answer is the smallest one.

• Email: consult@upeosoft.com
• Phone: 0116 888 777
• Web: upeosoft.com