Documentation and Handover: Surviving the Developer Who Leaves

Every business in Nairobi that has built something digital — a booking system, a SACCO member portal, an eTIMS-integrated invoicing tool, a clinic's patient records app — eventually faces the same quiet crisis. The developer who built it, or the agency that maintained it, moves on. Maybe they got a better offer in Kilimani, moved abroad, or simply stopped responding to WhatsApp messages. What's left behind is a system that works today but that nobody in the business fully understands. This is not a hypothetical. It is one of the most common and most preventable failures in small business technology across East Africa, and it rarely makes headlines because it happens quietly, one abandoned project at a time.

Why This Problem Is Worse in Kenya Than You'd Think

In larger markets with deep talent pools, losing one developer is an inconvenience — you post a job, hire a replacement, and the new person reads the documentation and gets up to speed. In Kenya, the market for skilled developers who deeply understand local business logic — M-Pesa integrations, KRA compliance requirements, SACCO regulatory reporting, clinic data handling — is smaller and more concentrated. Many SMEs rely on a single freelancer or a two-person agency rather than a full engineering team. When that person leaves, there often isn't a bench of equally qualified people waiting to step in cheaply. You are not just losing a staff member; you are losing the only person who knows where the API keys are, how the M-Pesa callback URL was configured, and why a particular workaround exists in the invoicing module.

Add to this the realities of how many small projects get built: tight budgets, compressed timelines, and a client who wanted the system working yesterday rather than documented thoroughly. Documentation is the first thing cut when a project is behind schedule, because it has no visible output on launch day. Nobody demos documentation. But six months later, when the developer is gone and something breaks at 11pm before a board meeting, its absence becomes very visible indeed.

The Hidden Cost of "It Just Works"

A system that works without anyone understanding it is not actually stable — it is fragile in a way that doesn't show itself until the worst possible moment. Consider a school management system that automatically sends fee reminders via SMS, or a clinic appointment system that syncs with a lab's results portal. These systems quietly depend on renewed domain names, SSL certificates, API tokens that expire, and third-party accounts (Safaricom Daraja, a hosting provider, an SMS gateway) that someone pays for annually. If the person who set these up leaves without documenting them, the business doesn't find out until a renewal lapses and the service stops — often without warning, because the failure is silent until a customer complains.

What Good Documentation Actually Looks Like

Documentation does not need to be an elaborate manual. For most SMEs, it needs to answer a short list of practical questions clearly enough that a reasonably competent new developer — or even a non-technical manager in a pinch — can find their way around without having to guess or reverse-engineer the system from scratch.

The Non-Negotiables

1. Access and Credentials Inventory

A written, centrally stored list of every account tied to the business's digital infrastructure: domain registrar, hosting provider, email service, Safaricom Daraja API credentials, payment gateway dashboards, database admin logins, and any third-party tools (SMS gateways, cloud storage, analytics). This should state who owns each account — ideally the business itself, not the developer's personal email — and where the login credentials are stored, such as in a password manager the business controls rather than in the developer's head or personal notes.

2. System Architecture Overview

A simple diagram or written description of how the pieces fit together: which server or cloud provider hosts what, how the app talks to M-Pesa or a bank's API, where customer data is stored, and how backups are taken and where they live. It doesn't need technical elegance. It needs to let a new person understand, in twenty minutes, what talks to what.

3. Operational Runbook

Step-by-step instructions for the things that go wrong regularly: how to restart the service if it crashes, how to check why an SMS or M-Pesa callback failed, how to restore from backup, how to renew an SSL certificate or domain. These are the tasks that, without a written procedure, require either guesswork or a frantic call to a developer who may no longer be reachable.

4. Business Logic and "Why" Notes

This is the piece most often missing, and the most valuable. Code tells you what a system does; it rarely tells you why. Why does the fee calculation round up instead of down? Why is there a special case for members who joined before a certain date? Why does the invoicing module check a particular status before generating an eTIMS-compliant receipt? These decisions usually trace back to a real business requirement, a regulatory nuance, or a past data problem that got patched around. Without notes explaining the reasoning, a new developer may "fix" something that was actually intentional — and break a compliance requirement or a customer-facing promise in the process.

Handover: Making It a Process, Not an Afterthought

Good documentation written after a developer has already left is far less useful than documentation built as part of a structured handover while they are still around to explain, demonstrate, and answer questions. If you know a developer or agency relationship is ending — whether due to resignation, contract completion, or a falling out — treat handover as a deliverable with its own timeline, not an informal afterthought squeezed into the last week.

Building Handover Into Contracts From the Start

The best time to think about an eventual departure is at the very beginning of the relationship, in the contract. Whether you're hiring a freelancer, an agency, or bringing on a full-time developer, the engagement terms should state plainly that all source code, credentials, and documentation belong to the business and must be handed over in a usable state, both during the engagement and at its end. This sounds obvious, but it is routinely left out, and disputes over who "owns" the code or the domain registration are common precisely because nobody wrote it down. Kenyan business owners should treat this clause with the same seriousness as a lease agreement — it protects continuity, not just intellectual property.

A Practical Handover Checklist

When a developer is leaving, however the departure happens, there is a minimum set of things to verify before they're gone for good: full source code transferred to a repository the business controls (not the developer's personal account), all credentials rotated and transferred to business-owned accounts, documentation reviewed in a sit-down session rather than just emailed over, a recorded or written explanation of any unusual or fragile parts of the system, and a clear statement of what ongoing costs exist (hosting, SMS credits, API subscriptions, domain renewals) and when they're due. If the relationship allows it, a short overlap period — even a few paid days or weeks — where the outgoing developer is available to answer questions while a replacement gets oriented is worth far more than it costs.

When the Exit Is Not Amicable

Not every departure is clean. Sometimes a developer leaves on bad terms, stops responding, or disputes payment and withholds access as leverage. This is a genuinely difficult situation, and the right response depends on specifics a business owner should discuss with a lawyer rather than guess at. What can be said generally: this is exactly why access to domains, hosting accounts, and payment gateway dashboards should be registered under the business's own official details from day one, not the developer's personal email or phone number. If a business discovers that critical infrastructure — a domain, a Safaricom Daraja app, a hosting account — is registered to a former developer personally, regaining control can be slow and sometimes requires formal escalation to the relevant provider. Prevention, by insisting on business ownership of accounts from the outset, is far easier than remediation after the fact.

Documentation Is Also a Compliance Issue

For regulated or semi-regulated businesses — SACCOs, fintechs, clinics handling patient data, schools handling student records — documentation isn't just an operational nicety; it intersects with obligations around data protection and financial compliance. If your business handles personal data, you are expected to know where that data lives, who can access it, and how it's protected — questions that are impossible to answer confidently if the only person who knew the answer has left without writing anything down. The Office of the Data Protection Commissioner expects data controllers to demonstrate reasonable organisational measures for protecting personal information, and "our developer knew but he's gone" is not a position any business wants to be in during an audit or after an incident. Similarly, if your systems touch KRA's eTIMS requirements or financial reporting obligations tied to the Central Bank of Kenya's oversight of payment service providers, you need documented, auditable processes — not institutional memory that walked out the door. Businesses in these categories should treat documentation as part of their compliance posture, and should confirm current specific requirements directly with the relevant regulator rather than relying on general guidance like this article.

Practical Steps for Resource-Constrained Teams

Most Kenyan SMEs don't have the budget for a dedicated technical writer or a DevOps engineer whose job is documentation. That's fine — the goal is not perfection, it's reducing the risk of total dependency on one person's memory. A few low-cost habits make an outsized difference: insist that credentials are stored in a shared password manager the business controls, not scattered across WhatsApp messages and personal notebooks; ask developers to write a short README for every system, even an imperfect one, as a condition of final payment; schedule a recorded screen-share walkthrough of the system before any contractor finishes a project, even if nobody is currently leaving — treat it as standard practice, not a crisis response; and periodically ask "if this person vanished tomorrow, could someone else keep this running?" If the honest answer is no, that's the signal to invest in documentation now, while it's calm, rather than later, while it's urgent.

None of this is glamorous work, and no developer enjoys writing documentation as much as building the next feature. But for a business whose daily operations — member contributions, patient bookings, fee payments, payroll — run through a system only one person understands, documentation is not bureaucratic overhead. It is the difference between a manageable staff transition and a genuine operational crisis. Build it in from the start, treat handover as a deliverable rather than a courtesy, and keep ownership of your own infrastructure firmly in the business's hands. The developer who leaves should be an inconvenience, not an emergency.