Hiring a software developer in Kenya: a buyer’s evaluation guide

Start with who performs the task, what information they receive, what decision they make and what must happen next. For an order system this might include a salesperson recording an order, a manager approving a discount, warehouse staff allocating stock and an accountant reconciling payment. Include exceptions such as a cancelled order or a customer who pays twice.

Show the developer an anonymised sample spreadsheet, form or report. Explain which part is slow or unreliable today. A good discovery conversation should reveal unclear rules rather than immediately promising an app. If your problem is primarily a public marketing website, use our website-specific selection guide instead of evaluating it as a large business system.

Ask what the supplier actually designed, built, integrated and supports in the work they show. Request a demonstration with sample data and the role of an ordinary staff user. A screenshots-only portfolio cannot demonstrate permissions, data export, error handling or day-to-day usability. Contact a reference only through an agreed introduction; do not expect another client's production credentials.

Review the Ken Designers portfolio as one source of project evidence, then discuss the requirements of your own operation. Similar work is useful, but it is not proof that your exact workflow is already covered. Ask where the proposed solution will differ and what the supplier needs to investigate before committing to scope.

The following questions turn vague promises into concrete evidence. Record both the answer and anything the supplier has not yet confirmed.

Security requirements should follow the risks of your system. Identify sensitive information, staff roles, who can export records and which operations need an audit history. Ask how access is removed when a staff member leaves, how secrets are kept out of public code and how backups are protected. Ask who will apply dependency and server updates after launch.

OWASP ASVS provides a basis for specifying and testing web application security controls. NIST SSDF provides a framework for secure development and responding to vulnerabilities. These are useful starting points for a procurement discussion; mentioning a framework is not a certification or proof that every control has been implemented. Request a risk-appropriate verification plan and evidence of the agreed checks.

Break the project into outcomes you can review: an agreed workflow, a usable prototype, a tested first release and a documented handover. Each milestone should have a named client decision maker and examples of what passing looks like. For instance, a stock transfer should affect the correct locations and leave an understandable history. 'Dashboard completed' is too vague to review fairly.

Ask how changes will be handled when discovery reveals a new requirement. A written change request should explain the effect on cost, delivery and existing features before work proceeds. Distinguish a defect against agreed behaviour from a new feature. This protects both sides from arguments at the final invoice.

Record which accounts are in your business name, your rights to the source code, any third-party licences and what happens when the contract ends. A subscription product and a custom-owned application have different handover expectations. Ask whether another developer can deploy and maintain the system using the documentation you will receive.

Support should say how incidents are reported, which hours are covered, what response means and what is charged separately. A promise of lifetime support without conditions is difficult to rely on. Ask for a tested backup restoration process and an exit export with readable records; an export that omits relationships or attachments may not be sufficient for migration.

Use the scorecard below to compare relevant experience, workflow fit, acceptance evidence, ownership and ongoing costs. A missing answer is a follow-up question, not automatic proof that a supplier is unsuitable. Do not add a numerical score to an unverified claim simply because it appeared in a brochure.

For a hypothetical distributor, a practical first phase might cover order entry, stock allocation and an export for accounting before adding forecasting. Test that sequence with the people doing the work. Share your workflows, users, sample reports and current tools when asking about our custom software development service. The software budget guide helps you prepare the cost discussion.