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

A useful software brief explains the business problem, the people and records involved, what the first release must do, and how the team will decide it works. This worked example is deliberately hypothetical: use it as a prompt for discovery, not as a specification for every organisation in Kenya.

Last updated: September 19, 2026.

Start with the current process

Follow one real request from its beginning to its final outcome. Record who acts, what information they use, where they wait, which system owns each record, and what happens on the exception path. Separate the problem to solve from features someone has already proposed.

If you have several candidate processes, use the workflow selection guide to compare their pain, clarity, expected benefit, and readiness.

Worked example: order-to-dispatch for a distributor

Assume, for illustration, a Nairobi distributor wants to replace order tracking split across email and spreadsheets. This is a sample brief only; it does not describe a Statum client or promise a particular result.

Problem to investigate: staff re-enter order details, managers cannot see which orders are waiting, and the warehouse learns about changes late. During discovery, measure the current time from a complete order request to dispatch, the number of manual handoffs, and the correction rate. The business owner must set a target after establishing that baseline.

Users and authority: sales staff create orders; warehouse staff review picking and record dispatch; an operations manager resolves exceptions; an administrator manages user access. A role matrix states which records each role can view and which actions it can perform.

First-release flow: received → reviewed → ready to pick → dispatched. Define explicit exception states for incomplete orders, unavailable stock, cancellation, and delivery problems. Record who moved an order, when, and why. Do not let an integration or notification silently mark an order dispatched.

Records and ownership: the new system owns operational order status and dispatch history. The existing accounting product remains authoritative for invoices and customer balances. Decide which customer and product fields are synchronised, which system may edit each field, and how conflicts are reviewed.

Migration and integrations: import only the agreed active customers, product records, and open orders. The business names a person to approve the mapping and reconcile record counts and totals before cutover. List each required interface, its owner, credentials process, failure behaviour, and test environment. Treat historical reporting, automatic accounting entries, and customer messaging as out of scope unless discovery confirms they are required.

Operations: agree who approves access, reviews alerts, answers staff questions, and resolves stuck orders. Specify backup frequency and a restore test, retention and access rules for customer information, support hours, training, and the handover needed for someone other than the original developer to operate the system. Set a budget ceiling, decision owner, and target release window before a fixed estimate is accepted.

Turn needs into acceptance checks

The following are sample acceptance checks for that hypothetical release. The business owner should adapt the data, target times, and exceptions before development starts.

Avoid acceptance statements such as “easy to use,” “fast,” or “secure” without a test. Name the test data, expected result, person who approves it, and evidence to retain. If the target depends on a live external service, define a sandbox test and a manual operating procedure for service interruption.

Keep scope and estimates honest

List exclusions as clearly as included work. A first release might exclude a native mobile application, automated route optimisation, advanced analytics, and editing invoices in the accounting system. These can be evaluated later using evidence from actual use.

Group work into discovery, first-release implementation, user acceptance, training, and support. Identify dependencies and who supplies each decision, data file, account, and test result. Estimate ranges only after the workflow, integrations, migration, and acceptance checks are understood. A fixed price attached to unresolved rules is likely to hide assumptions that will surface during delivery.

Custom software is one option. First compare process improvement, a configured product, and integration with tools already in place; build custom only where the verified requirements justify owning that system.

Close the estimate with explicit inputs

For this hypothetical distributor, the operations manager is the named business acceptance owner and signs off the agreed test results. Before estimating, attach a 30-day source-system extract and record average and peak orders per day, seasonal spikes, expected simultaneous users, and a growth assumption. If figures are unknown, keep the estimate conditional on measuring them instead of guessing. The distributor retains owner-level control of the production hosting or VPS account, domain and DNS, database, storage, and integration accounts. Name who approves access and spend, who can recover those accounts, and how provider access is handed over when a supplier changes.

Copyable first-release brief

Use these prompts to prepare a first draft before discovery; replace each prompt with your own evidence and decisions.

• Business problem and current baseline:
• First-release outcome and explicit exclusions:
• Users, roles, and permissions:
• Normal workflow and exception paths:
• Records, source of truth, and integrations:
• Migration inputs and reconciliation owner:
• Acceptance checks and test evidence:
• Hosting, access, backup/restore, and support owner:
• Dependencies, decision owner, budget ceiling, and target window: