Custom software cost in Kenya: scope, build or buy, and running costs

NairobiSites advertises custom software from KES 300,000 on its pricing page, checked 3 October 2026. That is one vendor's starting offer. It cannot establish the cost of your system, the average Kenyan project or a Ken Designers price. A small internal tool and a multi-branch stock system can involve very different responsibilities.

Ask a supplier what discovery is needed before a fixed proposal is possible. A quote made while key business rules are unknown should identify assumptions and exclusions. If you need a rough budget first, share your intended users, workflows, existing data and required integrations rather than asking only for the price of 'an ERP' or 'a CRM'.

Select a few representative tasks and run them in a candidate product with sample data. Include a normal task, an exception and a report the manager actually uses. Record where the product meets the requirement, where configuration is enough and where staff would still work around it in spreadsheets. Distinguish a preferred screen layout from a genuinely missing business rule.

Buying can be sensible when the process is standard and the product supports your roles and exports. Building can be sensible when important workflows cannot be handled without costly duplication or unreliable workarounds. Neither choice eliminates maintenance. Include subscription growth, implementation, training, integration work and the eventual exit process when comparing them.

A developer needs more than a feature list to estimate reliably. Describe quantities and rules: how many user roles, locations, record types and approval steps exist, how frequently data changes and what happens when a connection fails. Treat uncertain integration or migration work as an investigation rather than an invisible assumption.

Safaricom Daraja provides M-PESA and other Safaricom APIs for web and mobile integration. That availability is a starting point, not proof that a particular business account, checkout or software package is ready to use them. Provider access, supported use cases and production setup must be confirmed before promising a live integration.

Ask the developer to demonstrate pending, failed and duplicate payment scenarios with test data, then show how staff reconcile an order with the provider's records. The same approach applies to messaging, accounting and courier services: consider credentials, costs, failure handling and the person responsible for follow-up. A happy-path API demonstration alone does not show that the whole business process works.

Old records often contain inconsistent names, duplicate customers or stock totals with no transaction history. Decide which system is authoritative and who can approve corrections. Provide anonymised samples early; do not wait until launch to discover that an imported field has a different meaning in the new system.

Agree a trial import, validation report and cutover process. Identify totals or samples to reconcile, such as opening balances, stock quantities by location and outstanding orders. Keep a recoverable copy of the original data and decide how activity during the migration window will be handled. These are planning recommendations, not claims about the quality of your current records.

Use an evaluation period that fits your business. Add discovery, build, implementation and migration to hosting or subscriptions, maintenance, provider fees, staff training and expected changes. Compare the same period for a bought product. Show the assumptions separately so a change in user count or transaction volume is easy to discuss.

For a hypothetical distributor, start by measuring how long staff spend reconciling orders and where errors occur. Use your own observed hours and costs to assess potential value; do not assume a developer's promised savings will happen automatically. A system that removes one spreadsheet but introduces more manual checking may not deliver the intended benefit.

Prioritise one complete workflow, including permissions, reports and exception handling, rather than disconnected pieces of many departments. Define passing scenarios before building and have the actual staff run them. Include restoration, data export and handover in the scope rather than leaving them as a future favour.

Discuss proportionate security requirements using OWASP ASVS and secure-development practices such as NIST SSDF. These references help structure questions; they do not certify a proposal. Download the brief below and enquire about custom software development with your workflows and operating constraints. Use the hiring guide to compare supplier evidence.