A growing Kenyan business has outgrown its spreadsheets—but should it buy software, build its own, or combine both? Follow one practical decision from problem to solution.
Every Monday morning, Kamau’s operations team opens the same spreadsheet. One person updates customer orders, another checks stock, and someone else compares M-Pesa payments against WhatsApp confirmations. By lunchtime, there are already three versions of the file with names such as FINAL, FINAL-NEW, and FINAL-USE-THIS.
The system worked when the company was small. Now orders are being missed, staff spend hours reconciling information, and Kamau cannot see the state of the business without calling several people.
He knows the company needs better software. What he does not know is whether to subscribe to an existing product, commission a custom system, or keep the spreadsheet alive for another year.
This is a fictional example, but the decision is familiar to many growing Kenyan businesses. The expensive mistake is not always choosing custom software. Sometimes it is buying the wrong subscription, automating a process nobody understands, or building too much before proving what the team needs.
When business owners ask, “How much will software cost?”, the honest answer begins with another question: “What is the current problem costing you?”
For Kamau, the spreadsheet itself is free. The process around it is not. Employees lose time copying information. Stock errors create refunds. Delayed follow-ups cost sales. Management decisions are made using reports that are already out of date.
Those costs rarely appear as a single line in the accounts, but they accumulate every week.
Before comparing software prices, document one painful workflow from beginning to end. Who receives the information? Where is it entered? Who checks it? What happens when something is wrong? Which delay affects a customer or payment?
Good software does not begin with a feature list. It begins with a business problem that is specific enough to solve.
Kamau first looks at existing inventory and order-management products. This is sensible. If a reputable service already handles most of the workflow, paying a monthly subscription may be faster and less risky than creating a new platform.
Off-the-shelf software is particularly useful for common functions such as accounting, email marketing, customer relationship management, payroll, and basic stock control. The provider maintains the application, releases updates, and spreads development costs across many customers.
But “available” does not always mean “suitable.” A product may assume payment methods the company does not use, require constant connectivity, or charge for every employee who needs access. Staff can end up exporting data back into spreadsheets because an important local workflow does not fit.
Buying is the right decision when the business can adapt comfortably to the product. It becomes expensive when the team must create workarounds around the software every day.
Suppose Kamau discovers that no existing product connects customer orders, M-Pesa confirmations, warehouse stock, and delivery status in the way his team operates. That gap may justify custom software development.
A custom system can reflect the company’s actual roles, approvals, terminology, and reports. It can integrate with services the team already relies on and provide a simpler interface than a broad enterprise product full of unused modules.
The trade-off is responsibility. Custom software requires discovery, design, testing, deployment, training, maintenance, and security. It should not be treated as a one-time purchase that never needs attention again.
That does not automatically make it unaffordable. The cost depends heavily on scope. A focused internal tool for one process is very different from a complete ERP, customer mobile application, analytics platform, and marketplace launched at the same time.
After reviewing the options, Kamau may find that the accounting system already works well. Replacing it would create unnecessary risk. The real gap is between incoming orders, payment confirmation, and stock updates.
Instead of rebuilding everything, the company can keep the accounting product and create a focused operations layer that connects the missing steps. This blended approach combines stable existing tools with custom integrations, reports, or interfaces.
For many SMEs, this is the most practical route. Authentication, email delivery, payment services, cloud hosting, and common administrative functions do not need to be invented again. The investment can go toward the workflow that makes the business different.
An experienced technical partner should be willing to recommend this approach—even when it produces a smaller development project.
Once Kamau’s team begins discussing possibilities, the feature list grows quickly. Someone wants a mobile app. Another person asks for artificial intelligence. Management imagines customer loyalty, supplier portals, advanced forecasting, and ten new reports.
Each idea may be valuable, but building all of them at once makes the project slower, harder to test, and more expensive.
The first release should solve the narrowest complete problem. In Kamau’s case, that might mean capturing an order, confirming its payment, updating stock, and showing its delivery status. If that workflow saves time and reduces mistakes, the company has evidence for what to build next.
This is the purpose of a minimum viable product, or MVP. “Minimum” should not mean careless or unfinished. It means deliberately limited to the smallest experience that produces real business value.
The visible screens are only part of a software project. A responsible proposal also considers planning, user experience, data structure, security, testing, deployment, documentation, and training.
After launch, the system will need updates. Browsers and mobile operating systems change. Integrations evolve. Employees discover better ways to work. Security issues need attention. Hosting and support continue even after the initial build is complete.
A low quote that ignores these responsibilities can become more expensive than a clear proposal that includes them. Ask what happens after launch, who owns the source code and data, how backups work, and how future changes will be priced.
If a reasonably priced product supports the process well, Kamau should buy it. If an existing platform works but lacks one important connection, he should configure or extend it. If the workflow is central to how the company competes and generic tools keep creating friction, a custom build deserves serious consideration.
He should also be willing to wait if the process changes every week or the business model is still being tested. Software can strengthen a clear operation; it cannot create clarity on behalf of the business.
The final decision is not really “buy versus build.” It is how to produce the most useful outcome with the least unnecessary complexity.
Do not begin a software consultation with fifty features. Bring one workflow, the people involved, the current tools, and an example of where the process fails. That gives a developer enough context to compare subscription software, integration, automation, and a custom build honestly.
AvaBerg helps Kenyan businesses make that comparison before committing to development. We configure existing tools, build focused custom software, and create practical ERP systems around real operating needs.
Book a consultation and bring us the process your team is tired of fighting.
Explore related services
Need help implementing this?
Our team helps Kenyan businesses with software, security, and IT every day.
A familiar payment request, one convincing email, and a growing business can suddenly be in crisis. Here is why Kenyan SMEs are being targeted and how to respond.
A new employee, a shared password, and one unexpected payment request reveal how everyday habits shape an SME’s security—and how to improve them affordably.