Software Development Agreements in Kenya: Key Legal Terms for Tech Businesses

Software development agreements in Kenya set out who builds what, who owns it, how it is paid for and what happens when a project goes wrong. Whether you are a startup commissioning a platform, a company building internal systems or a software house serving enterprise clients, a clear written agreement is the best protection. Many technology disputes in Kenya start with an informal scope email or purchase order that never dealt with ownership, acceptance or liability. This guide explains the key terms of software development agreements in Kenya.

Why a written agreement matters

Without a proper agreement the client risks paying for software it may not be able to own, use or modify, or being locked out of source code if the relationship ends. The developer risks non-payment, open-ended scope and liability for delays that the client caused. A written agreement allocates those risks in advance, and it is far cheaper to settle terms at the start than to litigate afterwards.

Intellectual property ownership

Ownership of the code is usually the most important term. Under section 31(1) of the Copyright Act, 2001, copyright vests initially in the author. The proviso then says that where a work is commissioned by a person who is not the author’s employer under a contract of service, or is made in the course of the author’s employment under a contract of service, the copyright is deemed to be transferred to the person who commissioned the work or to the employer, subject to any agreement between the parties excluding or limiting the transfer. The statutory default therefore tends to favour a paying client, but it can be displaced by contract and may not fit hybrid, pre-contract or foreign-developer arrangements, so it should not be relied on alone.

Put ownership in writing. Section 33(3) provides that an assignment of copyright, and an exclusive licence, has no effect unless it is in writing signed by or on behalf of the assignor or licensor. Section 33(3A) adds that an assignment is not valid unless it is lodged at the Kenya Copyright Board and a certificate of recordal is issued and entered in the Assignment Register. A client who takes an assignment should therefore build recordal into the delivery checklist. Moral rights are separate: under section 32 the author keeps the right to claim authorship and to object to distortion or other derogatory treatment prejudicial to honour or reputation, even after the economic rights are transferred.

Background and foreground IP

A balanced agreement separates background IP, which is the developer’s pre-existing frameworks, libraries and tools, from foreground IP, which is the new code, designs and documentation created for the project. The developer usually keeps background IP and grants the client a licence to use it as embedded in the deliverables; foreground IP is assigned to the client. Define each category precisely, and list third-party and open-source components together with their licence terms, because disputes over which code belongs to whom are expensive after a breakdown.

Scope, deliverables and acceptance

Vague scope drives cost overruns and disputes. The agreement should describe features, functionality, performance requirements and technical specifications, and set a change control process for work outside scope. A formal acceptance procedure should state how the client tests deliverables against agreed criteria, the period within which it must report defects, and the period within which the developer must fix them. Acceptance is the point at which milestone payments fall due and, normally, risk in the deliverable passes to the client.

Pricing and payment milestones

Common pricing models are a fixed fee for well-defined projects, time and materials for agile work where requirements evolve, or a hybrid with a retainer plus charges for extras. Tie payments to milestones, such as a deposit on signing, payments on agreed deliverables and a final payment on acceptance, rather than paying everything up front. State the invoice and late payment terms, who bears taxes, and whether the client may withhold disputed amounts.

Warranties, liability and indemnities

The developer typically warrants that the software will materially conform to the specification for a defined warranty period, that it does not knowingly infringe third-party rights and that the developer is entitled to assign or license the IP. The client warrants that the data, content and third-party licences it supplies are lawful to use. Parties usually agree a liability cap, often linked to the fees paid, and exclude indirect and consequential loss such as lost profits and lost data. Without a cap, a developer faces open-ended exposure for business losses caused by a defect. Whether the cap and exclusions will be enforced depends on the wording and the facts, so draft them carefully.

Data protection

If the software handles personal data, the Data Protection Act, 2019 applies. Where the developer processes personal data for the client, it acts as a data processor, and the Act requires the controller and processor to enter into a written contract under which the processor acts only on the controller’s instructions and is bound by the controller’s obligations. Cover security measures, restrictions on use and disclosure, sub-processors, breach notification and return or deletion of data on termination. Our guide to data protection compliance for technology companies covers these duties in more depth.

Confidentiality, system access and source code

Developers often need privileged access to servers and production systems. Limit that access to the project’s purposes and require credentials to be revoked at the end. Under section 14 of the Computer Misuse and Cybercrimes Act, 2018, a person who causes a computer system to perform a function by infringing security measures, with intent to gain access knowing the access is unauthorised, commits an offence punishable by a fine of up to five million shillings, imprisonment for up to three years, or both. Pair strict access rules with a confidentiality clause; our guide to trade secrets in Kenya explains what to protect. Decide whether the client receives source code on delivery or only on specified release events if the developer fails or becomes insolvent, and consider an escrow arrangement for critical systems.