How to Choose a Software Development Company in Kenya

The best software development companies in Kenya are not the ones with the largest portfolios or the most confident pitches. They are the ones that ask uncomfortable questions about your operations before they talk about technology, can show you a system they built three years ago that is still running, and are willing to tell you when your idea is not worth building yet.

That is a low bar in theory and a rare one in practice. Nairobi has a deep pool of engineering talent and a much shallower pool of firms that combine it with delivery discipline. The difference rarely shows up in a proposal. It shows up in month five, when the requirements change and the original team has moved on.

Here is how to tell the difference before you sign.

The short version

You are not really buying code. You are buying a set of decisions, a working relationship, and an exit. The questions below test all three. If a supplier answers them with adjectives instead of examples, that is the answer.

Twelve questions worth asking

1. Who will actually write the code, and can I meet them?

Subcontracting is normal in this market and not inherently bad. Undisclosed subcontracting is a problem, because it changes who is accountable when something breaks. Ask for the names and roles of the people assigned, and ask whether any part of the work will be delivered by another company.

A good answer: names, roles, and evidence that those people are employed by the firm. A bad answer: "a dedicated team will be assigned after signing."

2. Can you show me a system you built that is still running?

Any firm can show a launch. Fewer can show something they built in 2022 that has been maintained, extended and kept secure since. Ask what has changed in it, what broke, and who supports it now. Maintenance is where engineering quality becomes visible.

3. What happens during discovery, and what do I get at the end?

Discovery should produce artefacts, not enthusiasm. At minimum: a workflow map, a list of the technical risks, a clear scope for the first release, and an estimate with assumptions. Ask to see a real example from a previous project, redacted if necessary.

If discovery is "free" and lasts one meeting, it is a sales call with a different name.

4. How do you decide what not to build?

Scope discipline is the strongest predictor of a project finishing. Listen for phrases like "that belongs in version two", "that is a process problem before it is a software problem", and "we would buy that rather than build it". A firm that agrees with everything you suggest is not being helpful; it is deferring the argument to a more expensive stage.

5. What does your testing actually look like?

Ask specifically: automated tests or manual only, what proportion of the critical paths are covered, whether there is a staging environment, and who signs off before a release. "We test thoroughly" is not an answer. "Every payment path has an automated test, and releases go to staging for a day before production" is.

6. How do you deploy, and how do you know when something is broken?

This question separates firms that build software from firms that operate it. You want to hear about automated deployments, environment configuration, logging, error tracking, uptime alerts, and a rollback procedure. If deployment is "the lead developer uploads the files", you have found the single point of failure.

7. Who owns the code, the repositories and the cloud accounts?

The correct answer is unambiguous: you do, from day one. Repositories, cloud accounts, domains, payment provider accounts and third-party services should be created in your organisation's name, with the supplier granted access. Waiting until the end to transfer ownership is how businesses end up negotiating for their own systems.

8. What does handover look like?

Ask what documentation you receive, whether your own team can be trained, and how long support continues after launch. A serious firm will have a handover checklist. A firm that treats handover as a threat to its retainer will be vague here.

9. How do you handle data protection?

Kenya's Data Protection Act 2019 applies to almost any system handling customer or employee data. Ask how they handle consent, retention, access control, and cross-border transfers. If you are collecting personal data at scale, ask whether a data protection impact assessment is needed and who will do it.

A firm that has never discussed the ODPC with a client is either new to regulated work or hoping you will not ask.

10. What does "AI" mean in your proposal?

AI is now a line item on every pitch. Ask which model or service, what data it receives, how outputs are evaluated, what happens when the model is wrong, and what the monthly cost looks like at your expected volume. A credible answer mentions evaluation, failure handling and cost per request. A weak answer mentions "cutting-edge AI" and nothing else.

11. What happens when we disagree, or when the scope changes?

Change is normal. The question is whether there is a process for it. Ask how new requests are estimated, who approves them, and how the schedule absorbs them. Firms with a change-control process tend to finish close to budget. Firms without one tend to have a difficult conversation at the end.

12. Can I speak to a client whose project did not go smoothly?

This is the most revealing question on the list, and most suppliers will not have a good answer. Every firm has had a difficult project. The ones worth hiring can describe what went wrong, what they changed, and what the client would say now. A portfolio of only successes is a portfolio with the evidence removed.

The contract terms that matter

You do not need a 40-page agreement for a first project, but you do need these terms in writing.

• Scope and acceptance criteria. What is being delivered, and how both parties will agree it is done. Tie payments to acceptance, not to the calendar.
• Intellectual property assignment. Clear language transferring ownership of the code, designs, documentation and data to you on payment.
• Change control. How new work is priced and approved, and what happens to the timeline when it is.
• Confidentiality and data handling. Who can access your data, where it is stored, and what happens at the end of the engagement.
• Warranty. Typically 30 to 90 days for defects. Distinguish defects from new requirements.
• Termination. Notice period, payment for work completed, and a clean handover obligation. A contract with no exit is a contract you cannot enforce.
• Liability. A cap is normal. A cap set at one month's fees for a system that runs your operations is not.

Red flags, in rough order of seriousness

• A fixed price and a firm delivery date before anyone has looked at your data or your workflow.
• No questions about your business in the first meeting.
• Portfolio screenshots with no explanation of what the system does or whether it is still running.
• Pricing per screen or per page, which rewards adding screens and punishes simplifying.
• No mention of testing, deployment, monitoring or support until you raise them.
• Undisclosed subcontracting, or a team that changes after signing.
• "We do everything" — web, mobile, AI, blockchain, ERP and marketing — with no evidence of depth in any of them.
• Pressure to sign before you have spoken to a reference.
• AI claims with no named model, no evaluation approach, and no cost estimate.
• Reluctance to put IP ownership or handover in writing.

What good actually looks like

A good partner will slow you down slightly at the start and speed you up later. They will ask what happens to an order when the payment callback never arrives. They will want to see the spreadsheet your team actually uses, not the process diagram from the operations manual. They will suggest cutting a feature you were excited about because it does not earn its complexity.

They will also be honest about what they are not good at. A firm that builds web applications and says so is more useful than one that claims to build everything, because you can plan around the boundary.

One practical test: ask each shortlisted firm to describe the last project that went over budget, and why. The answer tells you more about how they will behave when yours does than any portfolio ever will.

If you are comparing proposals and want a second opinion on the technical scope, send it over. We will tell you what looks thin, whether the estimate is plausible, and where the risk sits — even if you end up building it elsewhere.