Technical Due Diligence for Kenyan Startups Raising Capital

What technical due diligence actually is, and why it catches founders off guard

When a fund or angel investor decides to seriously consider putting money into your company, they don't just look at your revenue numbers and your pitch deck. At some point — usually after a term sheet is signed but before money moves — someone technical, either on the investor's team or a contracted specialist, will ask to look under the hood of your product. This is technical due diligence, and for a lot of Kenyan founders it's the first time anyone outside the founding team has ever formally examined the codebase, the infrastructure, and the operational practices behind the business. It's a different kind of scrutiny from the financial and legal due diligence most founders expect. It's less about whether your numbers add up and more about whether the thing generating those numbers is built to survive, scale, and not blow up in someone's face six months after the cheque clears.

For a Nairobi-based fintech, a school management SaaS, a SACCO digitisation platform, or an agency-turned-product-company, this process can feel intrusive and, frankly, a little unfair if you weren't expecting it. Most Kenyan startups are small teams — sometimes a single developer-founder, sometimes two or three engineers wearing five hats each — who built something that works, got it in front of paying customers, and are now being asked to explain their disaster recovery plan or produce evidence of who actually owns the intellectual property. The gap between "it works and customers are happy" and "it would pass institutional due diligence" is usually wider than founders expect, and closing that gap takes time you often don't have once a raise is already in motion.

Codebase ownership and IP: the question that kills deals quietly

One of the first things a diligence reviewer checks is whether the company actually owns its own code. This sounds obvious until you look at how many early-stage Kenyan products were built. A founder hires a freelance developer or a small agency to build the MVP, pays them from a personal M-Pesa account or a bank transfer with no formal contract, and the developer hands over a GitHub repository link. Nobody signs anything transferring intellectual property rights. Years later, that freelancer is untraceable, has moved to a different country, or simply disputes ownership when the company is suddenly worth something. Investors know this pattern well and will ask for the paper trail: contracts with every contractor and past employee that clearly assign IP to the company, not just a licence to use it.

The fix is straightforward but takes discipline: every person who has ever touched your code, from a one-week contractor to a co-founder who left on bad terms, should have signed something that unambiguously assigns their work product to the company. If you don't have this in place retroactively, get proper legal advice now on how to remedy gaps before a term sheet is on the table, not after a lawyer on the other side flags it. This is also where you should be honest with yourself about who has admin access to your GitHub or GitLab organisation, your domain registrar, your cloud accounts, and your app store listings. It is embarrassingly common for a startup to realise, mid-diligence, that the domain is registered in a former employee's personal name, or that nobody currently at the company has the password to the Google Play developer account.

Infrastructure, uptime, and the honest answer to "what happens when Safaricom's network hiccups?"

Kenyan startups building on mobile money rails, USSD, or SMS gateways live with a layer of dependency that Silicon Valley due diligence checklists don't naturally account for, and a good technical reviewer familiar with the region will probe it directly. What happens to your platform when an M-Pesa API integration times out during peak hours? Do failed transactions get queued and retried, or silently dropped? If you're running core services on infrastructure hosted outside Kenya — which most startups do, using providers priced in US dollars — how do you handle latency for users on patchy mobile data in Kisumu or Garissa versus fibre in Nairobi's CBD? None of this needs to be perfect, but a reviewer wants to see that you've thought about it and have monitoring in place that would tell you if something failed, rather than relying on customer complaints as your alerting system.

Related to this is the unglamorous but critical question of backups and disaster recovery. Ask yourself right now: if your production database disappeared this evening, what is the most recent point you could restore to, and how long would that restoration take? A surprising number of small teams can't answer this with confidence. Diligence reviewers will ask for evidence — not a description of what you intend to do, but logs or dashboards showing backups actually running and, ideally, evidence that a restore has been tested at least once. Power interruptions are a real operational fact of life in Kenya, and while most competent cloud providers insulate you from local power issues if you're hosted properly, your own office systems, physical backups, or on-premise components (common in clinics and schools running some sort of local server) need their own resilience plan.

Data protection: this is no longer optional groundwork

Any Kenyan startup handling personal data — and if you have customer accounts, patient records, student information, or loan applicants, you are handling personal data — needs to be able to speak credibly about compliance with data protection law and registration status with the Office of the Data Protection Commissioner. Investors, particularly those who've been burned before or who have their own compliance obligations to satisfy, will ask pointed questions: are you registered as a data controller or processor where required, do you have a privacy policy that reflects what your systems actually do rather than a template copied from another country's website, do you have a documented process for handling a data subject's request to access or delete their data, and do you have a plan for what happens if you suffer a breach. If you're not confident about your current obligations under Kenyan data protection law, this is an area where you should get a lawyer or compliance consultant to confirm your specific status rather than guessing — the requirements and thresholds can be specific to your sector and the volume and type of data you hold, and this article won't pretend to give you exact figures or deadlines that could be wrong or outdated by the time you read this.

For fintechs specifically, there's a second layer: depending on what you're doing — lending, payments facilitation, savings products — you may fall under some form of Central Bank of Kenya oversight or licensing regime, or you may be a service provider that rides on a licensed partner's rails without needing your own licence. This distinction matters enormously to investors because it affects both legal risk and how fast you can scale. Don't guess at your own regulatory position for the benefit of a pitch deck. Get a definitive answer from a lawyer familiar with CBK's current framework, and be prepared to show investors the documentation of that assessment, not just a confident verbal claim.

Tax and financial systems integration: eTIMS and the paper trail

Increasingly, Kenyan businesses of a certain size are expected to integrate with KRA's eTIMS system for invoicing, and any startup with real revenue should expect a diligence reviewer to check how transactional data flows from your product into your accounting and tax reporting systems. This isn't really a "technical" question in the narrow engineering sense, but it sits squarely in technical due diligence because it's about system integrity: can you show a clean, auditable trail from a customer paying you — via M-Pesa, card, or bank transfer — through to that transaction being reflected in your books and your tax filings? Investors worry about businesses where revenue reported to them doesn't reconcile cleanly with revenue reported to KRA, and mismatches here, even innocent ones caused by manual processes and human error, slow down or kill deals. If your integration with eTIMS or your general invoicing hygiene is still manual or ad hoc, it's worth tightening this before diligence starts rather than trying to explain it away during.

Team, documentation, and the "bus factor" problem

A specific thing diligence reviewers probe for is what's sometimes called the bus factor: how many key people would need to disappear for your company to be in serious trouble? In a lot of small Kenyan teams, the honest answer is one or two. If your lead developer is the only person who understands how the payment reconciliation job works, or the only one with production server access, that's a red flag investors will note even if they don't say it outright. Documentation is the unglamorous antidote here — not exhaustive corporate wikis, but enough written material (architecture diagrams, a runbook for common incidents, a list of every third-party service you depend on and who owns the account) that a new hire could get oriented without the founder personally walking them through everything.

Preparing without panicking

If you're a small team with limited budget, you cannot and should not try to build enterprise-grade everything before a raise. Investors backing early-stage Kenyan companies generally understand you're not running a bank's IT department. What they're really testing is whether you understand your own risks and have sensible, proportionate controls in place — and whether you're honest about the gaps rather than caught flat-footed by a question you'd never considered. Before you start fundraising conversations, do your own internal audit: list who has access to what, confirm your IP assignment paperwork is complete, check that backups actually run and have been tested, get clarity on your data protection and, if relevant, financial services regulatory status from a qualified professional, and make sure your revenue and tax records reconcile cleanly. None of this is expensive compared to the cost of a raise stalling or a valuation dropping because a reviewer found something that made them nervous. Treat technical due diligence not as an exam you're studying for at the last minute, but as a mirror of the operational discipline your business should have anyway, capital raise or not.