Business Software for Kenyan SMEs: Buy, Build or Customise?

Choosing business software for SMEs in Kenya comes down to one question: is your way of working common enough that someone already sells a product for it, or different enough that you should own the system? Subscribe when a product fits most of what you do, customise when it nearly fits, and build only when the process is what sets you apart or nothing on the market handles your Kenyan requirements.

That sounds simple, and the decision still goes wrong all the time. Owners buy a famous international package and spend a year working around it, or commission a custom system for something a KES 3,000-a-month app would have handled. This guide gives you a way to decide, with the local tests that matter here: M-Pesa, KRA eTIMS, SMS and WhatsApp, and where your data lives.

Signs your business needs a system

Software is not a reward for growing. It is a fix for specific pain. Before you look at any product, write down where the work is actually breaking. These are the symptoms we hear most from owners:

• Money arrives faster than it is recorded. M-Pesa messages pile up on the cashier's phone and get matched to customers on Friday afternoon, if at all.
• The same customer is typed three times. Once in WhatsApp, once in the quote, once more in the invoice book.
• You cannot answer simple questions quickly. "Who owes us money?" or "How much stock is at the Kisumu branch?" takes a phone call and a day.
• Work depends on one person's memory. When the office manager is on leave, follow-ups stop.
• Staff see things they should not. The whole team has access to the file with margins and salaries because there is no other way to share it.
• Branches report differently. Head office rebuilds every branch's numbers into its own format each month.

If two or more of these sound familiar, a system will pay for itself. If none do, keep your money; a well-run spreadsheet may still be the right tool, and our post on when to move off spreadsheets covers that threshold in detail.

The useful next step is to name the one process that hurts most. Not "we need an ERP", but "we lose track of quotes after we send them" or "school fees reconciliation takes the bursar four days every term". That single sentence drives every decision below.

Off-the-shelf SaaS: pros and limits

Software-as-a-service (SaaS) is a ready-made product you rent, usually monthly, and use through a browser or app. Accounting packages, point-of-sale apps, payroll tools, CRMs and helpdesks all come in this form.

Where SaaS wins

• Speed. You can sign up this afternoon and be invoicing tomorrow.
• Low upfront cost. No development bill; you pay as you go.
• Someone else maintains it. Security patches, backups and new features are the vendor's job.
• Proven processes. Thousands of businesses have already found the bugs in standard workflows like invoicing or payroll.

Where it falls short in Kenya

• Per-user pricing adds up. A tool priced in dollars per seat looks cheap for three users and painful for twenty, and exchange-rate swings move your bill every month.
• Local payments are often an afterthought. Card payments are built in; M-Pesa may need an add-on, a middleman or manual entry.
• You adapt to the software. If your process differs from the vendor's assumption, your team works around it, usually in a spreadsheet on the side.
• Support time zones. A ticket answered overnight from another continent costs you a working day.
• Your data, their terms. Exports may be partial, and if the vendor raises prices or shuts down, moving is hard.

None of this rules SaaS out. For standard back-office work such as bookkeeping and payroll, a well-known package is nearly always the sensible choice. The trouble starts when you try to force a generic product to run the part of the business that is actually unusual.

Customising existing products

There is a middle path that many owners miss. Instead of choosing between "rent as-is" and "build from nothing", you take an existing product and adapt it. This comes in three forms:

1. Configuration. Most decent products let you set up your own fields, document templates, approval steps and user roles without any code. Always exhaust this first; it is free and survives upgrades.
2. Integrations. Connecting the product to something else, for example pushing M-Pesa payments into your accounting package, or sending new website enquiries straight into your CRM. This usually involves a developer writing a small connector using the product's API.
3. Industry products built for Kenya. Some products are designed for one sector and already handle local needs. A school system that reconciles Paybill fee payments to each student, or a loan system that posts M-Pesa repayments to the ledger, starts much closer to your process than a generic tool does.

The risk with customisation is going too far. Heavy changes to someone else's product can break when they release an update, and you end up paying twice: the subscription and the developer who keeps patching it. A useful rule is that if your customisations cost more each year than the subscription, it is time to price a custom build properly.

Building custom software

Custom software is designed around your process and owned by you. It is the right choice in fewer cases than developers like to admit, but when it fits, nothing else comes close.

Build when

• Your process is how you compete. A logistics firm with its own dispatch rules or a lender with an unusual product structure should not bend those to fit a template.
• You need several things joined that no single product joins: say, an online order form, M-Pesa collection, stock across three shops and SMS updates to the customer.
• Per-user fees would grow to more than the cost of owning the system over three to five years.
• You have tried two or three products and each needed a spreadsheet alongside it to work.

Do not build when

• The process is standard accounting, payroll or tax filing. Use established products for those.
• You cannot yet describe the process clearly. Software freezes a process; if yours changes every month, run it manually or in a flexible tool for a while longer.
• Nobody in the business can spend a few hours a week answering the developer's questions during the project.

Custom does not mean "everything at once". The best projects start with a small first version covering the most painful process, go live, and grow from there. Our walk-through of the custom software development process explains what you will be asked to provide at each stage.

Kenyan must-haves: M-Pesa, eTIMS, SMS, WhatsApp

Here is where the decision gets local. Whatever route you choose, test it against these requirements before you sign. A beautiful product that fails two of them will cost you more in workarounds than it saves.

A few notes on the trickier rows. On eTIMS, KRA's requirements have been rolled out in stages and they apply differently depending on your tax status, so confirm your own obligations on kra.go.ke or with your accountant rather than relying on a software salesperson. On M-Pesa, Safaricom's Daraja developer portal is the official route for integrations, and any serious vendor should be comfortable explaining which Daraja services they use. On data, the Office of the Data Protection Commissioner publishes guidance on what controllers and processors must do; "the cloud" does not move your responsibility to the vendor.

Two further local realities deserve a line in your requirements. Power and connectivity: if your staff work from a branch in Kitale on patchy 3G, ask how the system behaves on a slow connection and whether anything works offline. And language: if counter staff or customers prefer Swahili, check whether templates and messages can be written in it.

Budgeting and phasing

The sticker price is the smallest part of what software costs. Budget across three years, not three months, and include everything below.

What to include in the budget

• Licence or build cost. Monthly subscriptions times users times 36, or the one-off development fee.
• Setup and data migration. Cleaning and loading your customer list, opening balances, stock or student records. Often underestimated.
• Integrations. M-Pesa, SMS, eTIMS, your website. Each is a small project of its own.
• Hosting. Included in SaaS; a separate line for custom systems.
• Support and maintenance. Security updates, bug fixes and small changes after launch.
• Training and staff time. The hours your team spends learning, and the slower weeks while they adjust.

A worked example in KES

Say a building-supplies business in Machakos with eight staff wants to stop losing quotes and chasing unpaid invoices. Here are its two broad options over three years, using round illustrative figures rather than any real vendor's prices:

• International SaaS CRM plus invoicing add-on at an assumed KES 3,500 per user per month: 8 users × 3,500 × 36 months comes to roughly KES 1,000,000 before any M-Pesa connector or setup help.
• Custom quote-to-invoice system at an assumed KES 350,000 to build, plus an assumed KES 10,000 a month for hosting and support: about KES 710,000 over the same period, and the business owns it.

Change the assumptions and the answer flips: at three users the SaaS option is far cheaper, and if the business needs only standard invoicing, a local product with a one-off licence may beat both. The point is to do the sum, not to assume. For reference, Edgecom's custom web apps and systems start from KES 100,000 plus 16% VAT, with most systems delivered in four to eight weeks for a first phase.

Phase it

Whichever route you take, roll out in stages. A sensible sequence for most SMEs:

1. Phase 1: the most painful process, live for real users within weeks. For many businesses that is getting paid: invoices plus M-Pesa matching.
2. Phase 2: the process that feeds it, such as leads and quotes, or orders and stock.
3. Phase 3: reporting, customer self-service and automation such as SMS reminders.

Each phase should be useful on its own. If the project stopped after phase 1, you should still be better off.

Choosing a development partner

If you are customising or building, the partner matters as much as the technology. Experience in your sector helps, but how they work matters more. Use this list in your first meeting:

1. Ask to see a live system they built, not just screenshots. A demo login tells you more than a portfolio page.
2. Ask how they will learn your process. Good partners want to sit with the people who do the work, not just the director.
3. Ask who owns the source code and the data at the end, and get the answer in the contract.
4. Ask how they handle M-Pesa. They should talk confidently about Daraja, callbacks, unmatched payments and reversals.
5. Ask what happens after launch. Who fixes bugs, how fast, and what it costs. A partner who goes quiet after the final invoice leaves you stuck.
6. Ask for a phased quote. A single lump sum for a large system is a warning sign; phases with clear deliverables protect both sides.
7. Check they will tell you not to build. If a partner never suggests an existing product, they are selling development, not solving your problem.

Sector products are worth a look before you commission anything. If you run a SACCO, read our SACCO management software checklist; schools should start with our guide to school management system features. If your main pain is the quote-to-payment cycle, Edgecom CRM covers leads, quotations, invoices, M-Pesa payments and receipts in one place, and it is worth comparing against the international CRMs on that specific flow.

A one-page decision rule

If you remember nothing else, use this:

• Standard process, standard needs (bookkeeping, payroll): subscribe to an established product.
• Standard process, Kenyan gaps (needs M-Pesa matching, eTIMS, SMS): look for a local or sector product first, then customise with integrations.
• Your own process, central to how you earn: build, starting small, with a partner who will phase it.
• Not sure yet what the process is: stay manual a little longer and write the process down first.

If you would like a second opinion on which side of that line your business sits, our system development team is happy to look at your current process and tell you honestly whether to buy, customise or build.