How to Scope Custom Software in Kenya: A Practical First-Release Checklist

A custom system should begin with a business problem, not a long list of features. For a company in Kenya, the right first release might connect an existing payment service to an operations dashboard, replace a fragile approval process, or give a field team one reliable place to record work. It does not have to replace every tool on day one.

Start with the workflow

Write down how the work happens today before choosing technology. Follow one request from the first customer or staff action to the final report. Note where information is entered, who approves it, which files are attached, and what happens when something is missing.

This exercise normally exposes the real problem. The business may not need a large platform. It may need one shared record, a clear owner, and a reliable handoff between two systems.

A practical scoping process

1. Choose one process

Pick a process that happens often enough for the team to understand it and that causes visible friction. Examples include customer onboarding, school fee collection, stock requests, service bookings, loan applications, or delivery updates.

Avoid combining several unrelated processes into the first release. A narrow scope makes it easier to test whether the new system is actually helping.

2. Define the records

List the records the process depends on. Depending on the business, these could be customers, orders, payments, members, students, stock items, vehicles, or service cases.

For each record, decide which system is authoritative. If the same customer or payment is copied into three spreadsheets, decide where the trusted version will live and how the other systems will receive updates.

3. Map roles and decisions

Write down who may create, view, approve, edit, or reverse each record. This is more useful than saying the system should be secure in general terms. It gives the developer something specific to implement and test.

Include the exceptions. What happens when an approval is rejected? What happens when an M-Pesa callback arrives twice, a mobile number is wrong, or a connection fails after a customer has paid?

4. Choose the smallest useful release

A first release could contain a login, a small set of records, an approval path, a report, and one or two integrations. It should also include audit history, backups, error handling, and a way for an authorised person to correct a mistake.

Do not leave these operational details until the end. A system that works in a demonstration but has no ownership or recovery process is not ready for daily use.

Questions to answer before development

Before requesting a proposal, prepare answers to these questions:

• Who will use the system and what should each role be allowed to do?
• Which existing services must be connected, such as M-Pesa, SMS, WhatsApp, accounting, or a customer portal?
• What reports does the team need every day or month?
• Which actions require approval or a second person to review them?
• What should happen when an integration is unavailable?
• How will the business test, train, and support the system after launch?

The answers will change the design, timeline, and cost. That is why a useful discovery conversation is usually more valuable than starting with a generic feature list.

When custom software is not the right answer

An off-the-shelf product may be the better choice when the workflow is common, the business can accept its rules, and the total cost of adapting it is lower than owning a custom system. A careful integration may also solve the problem without replacing the existing tools.

Custom software makes more sense when the process is central to the business, the existing tools create repeated work, or the business needs controls and integrations that a general product cannot provide.

Statum helps organisations in Kenya and worldwide plan and build custom software, integrations, and business systems. Start with the custom software development service or talk to Statum about the workflow.