</>CodeWithKarani

The 12 Clauses Every Software Contract Needs: A Checklist for Kenyan Developers

Karani GeoffreyKarani Geoffrey9 min read

Most developers think a contract is for the courtroom. It is not. The Kenyan reality is that a dispute over KES 900,000 will almost never see a courtroom, because the legal cost and the two years of your life are worth more than the money.

A contract is for month three. It is for the WhatsApp message that says "we assumed the mobile app was included", and for you being able to reply calmly with a clause number instead of an argument. The contract is a memory device for a relationship that has stopped being friendly.

One thing before the checklist: I run a software company, I am not an advocate, and none of this is legal advice. Treat every item below as something to look for and to raise with a Kenyan advocate before you sign anything that matters.

Two things about Kenyan law worth knowing before you draft anything

First, do not assume you own the code you were paid to write. The Copyright Act (Cap 130) treats computer programs as literary works, and section 31 provides that copyright vests initially in the author, but that where a work is commissioned by someone who is not the author's employer, the copyright is deemed transferred to the person who commissioned it, subject to any agreement between the parties excluding or limiting that transfer. Read that twice. The statutory default for commissioned work in Kenya tends to run toward the client, not toward you. Developers who learned their instincts from American blog posts about "work for hire" often have this exactly backwards.

Second, section 33 provides that no assignment of copyright and no exclusive licence has effect unless it is in writing signed by or on behalf of the assignor. So the paperwork is not decoration. It is the mechanism.

What this means practically: if you intend to keep or reuse anything, say so in writing, in the contract, before you start. And have an advocate confirm how these provisions apply to your specific arrangement, because the interaction between the statute and your particular wording is exactly the kind of thing that is worth a few thousand shillings of professional time.

The twelve clauses

1. Parties and authority

Full registered names, company numbers, physical addresses, and the name and title of the person signing. If the person signing is not a director, ask what authority they have. Contracts signed by an "operations manager" of a company that later says he had no mandate are a familiar way to lose money.

2. Scope, by reference to a separate document

Never put the scope inside the contract body. Put it in an annexed specification, referenced by name, version and date: "Annex A, Functional Specification v1.3, dated 12 March". Then the specification can be revised through change control without reopening the whole agreement. A scope that says "development of an inventory management system" is not a scope, it is a wish.

3. Assumptions and client obligations

The most valuable clause in the document and the one almost nobody writes. Your price and timeline assume things. List them: named client project owner with decision authority, feedback within five working days, test data provided by a stated date, access to their existing system, availability of their accountant for the chart of accounts, staff released for training. Then state the consequence: if a client obligation is missed, timelines extend day for day and standby time is chargeable at your day rate after a stated grace period.

This single clause converts "you are late" into "we are both late, and here is the log".

4. Change control

Define what a change is, who can request one, and the rule that no change is binding until it is written and signed by both parties with a stated cost and schedule impact. Add the sentence that saves relationships: work will not begin on a change until it is signed. Keep a change register in the same shared folder as the specification.

5. Payment schedule and milestones

Tie money to deliverables, never to dates. A typical shape: 40 percent on signature, 30 percent on acceptance of a defined build milestone, 20 percent on user acceptance sign-off, 10 percent thirty days after go-live. State invoice due days (fourteen or thirty), the interest rate on overdue amounts, and the right to suspend work after a stated number of days of non-payment. Suspension rights are far more useful than termination rights because you actually use them.

6. Tax and invoicing

State whether prices are exclusive of VAT (standard rate 16 percent). State how withholding tax is handled, since resident professional service fees are subject to withholding at 5 percent and many corporate clients deduct at source. Require the client to supply the withholding tax certificate within a stated period, because without it you cannot claim the credit. Confirm the mechanics with your accountant, and note that electronic invoicing requirements have been tightening, so agree in writing which invoicing system you will use.

7. Acceptance and deemed acceptance

Define the test: what the client will test, against which document, within how many working days. Define what counts as a defect (a failure against the specification) versus a change request (something the specification does not say). Then the clause that stops projects hanging forever: if the client does not submit written defects within the acceptance period, the deliverable is deemed accepted. Without deemed acceptance, milestone four never arrives.

8. Intellectual property

Separate three categories explicitly.

  • Foreground IP: what you build specifically for this client under this contract. Usually assigned to them.
  • Background IP: your pre-existing libraries, boilerplate, deployment scripts, internal frameworks and any generic component you will reuse. These should remain yours, granted to the client under a perpetual, non-exclusive, royalty-free licence for use in the delivered system. Otherwise you sell your toolbox with every job.
  • Third party and open-source components: listed, with their licences, so nobody is surprised later. If you are delivering on ERPNext or any other GPL or AGPL codebase, the licence of the underlying platform is a fact you disclose up front, not a discussion for month eight.

Make the assignment of foreground IP conditional on full payment, in the same sentence as the assignment. That one condition has recovered more final invoices than any other line I have written.

9. Warranty and support are different things

Warranty: for a defined period after acceptance (thirty to ninety days), you fix defects against the specification at no charge. Support: everything else, priced separately as a retainer or by the hour. If the contract does not draw this line, "support" becomes an unpaid subscription to the client's ideas.

10. Limitation of liability

Cap your total liability at the fees actually paid under the contract, or a stated multiple of monthly fees for retainers. Exclude indirect and consequential losses, loss of profit and loss of data, subject to whatever a Kenyan advocate tells you is enforceable here. A KES 800,000 project that exposes you to a KES 40 million business interruption claim is not a project, it is a lottery ticket with the odds inverted.

11. Confidentiality and data protection

Mutual confidentiality, with a defined term and defined exceptions. Separately, if you will touch personal data (payroll, customers, patients, students) the Data Protection Act, 2019 is relevant and the contract should say who is the data controller and who is the processor, what you may do with the data, security expectations, breach notification timelines, and what happens to the data at the end. This is another point to raise with an advocate rather than copy from a template, particularly if data leaves Kenya through your hosting provider.

12. Termination, exit and disputes

Termination for convenience with notice, and payment for all work performed to the termination date plus committed costs. Termination for cause on material breach with a cure period. Then the exit provisions, which matter more than the termination trigger: what is handed over, in what format, within how many days, whether credentials and repositories transfer, and whether you will provide paid transition assistance.

For disputes, an escalation ladder beats going straight to court: named senior people meet within fourteen days, then mediation, then arbitration in Nairobi under a named set of rules. Ask your advocate whether arbitration makes economic sense for your contract sizes, because for smaller values it can cost more than the dispute.

The pre-signature checklist

CheckPass condition
ScopeAnnexed spec with version and date, referenced in the contract
AssumptionsClient obligations listed with a stated consequence for delay
MoneyDeposit up front, milestones on deliverables, suspension right for non-payment
TaxVAT position stated, withholding tax and certificate handling stated
AcceptanceDefined test period, defect versus change definition, deemed acceptance
IPForeground assigned on full payment, background retained and licensed
WarrantyDefined period, defined as defects only, support priced separately
LiabilityCapped at fees paid, consequential loss excluded
DataController and processor roles named if personal data is involved
ExitHandover contents, format, timeline and paid transition terms

The three clauses clients push back on, and what to trade

  • Deemed acceptance. Clients hate it. Trade a longer acceptance window (fifteen working days instead of five) rather than removing the clause. The clause is the point; the duration is negotiable.
  • Liability cap. Corporate procurement will push for uncapped liability. Offer a higher cap, a multiple of fees, or carve-outs for confidentiality breach and gross negligence. Uncapped liability on a fixed-fee contract is not a risk a small firm can hold.
  • IP assignment on payment. Clients want assignment on creation. Offer assignment on creation with an automatic reversion or a licence suspension on non-payment, and let your advocate word it. Do not simply give it up.

For small jobs, do not send a twenty page contract

Under about KES 300,000, a two page document does most of the work: parties, scope by reference to the quote, price and payment schedule, acceptance with deemed acceptance, IP on full payment, liability capped at fees, and a short exit clause. Signed by email is a record. No signed record at all is the actual risk, not the missing clauses.

The contract you never read again is the one that worked. That is not because it was never needed. It is because it was written before anyone was angry.

#Contracts#Freelancing#Business of Software#Kenya#Intellectual Property
Keep reading

Related articles