Website Development Contract in Kenya: What It Should Include

A website development contract in Kenya does not need to be long, but it needs to exist in writing, be signed by both sides, and answer seven questions: what is being built, by when, for how much, who owns the result, how you will test it, what happens after launch, and what happens if the project stops. This guide goes through each clause in plain English so you can read a supplier's agreement and spot what is missing.

It is written for business owners, not lawyers, and it is not legal advice. For large or unusual projects, have an advocate look over the final document.

Why a WhatsApp chat is not a contract

Plenty of Kenyan websites are agreed over WhatsApp. "Sawa, 30k for the site, I start Monday." It feels efficient until something goes wrong. Then both sides scroll through months of messages, voice notes and forwarded screenshots, and each finds evidence for a different version of the deal.

Chats are poor contracts because they are scattered, informal and silent on the hard questions. Nobody writes "and the domain will be registered in your company's name" in a chat, so nobody agreed to it. A two-page document fixes that. It is also a good test of a supplier: a firm that will not commit its promises to paper is telling you something. If you are still choosing who to work with, our buyer's guide to hiring a web design company covers that stage.

Scope of work and deliverables

The scope clause describes exactly what you are paying for. Vague scope is the root of most arguments about "extras".

A good scope section includes:

• The pages by name, and roughly what goes on each.
• Features and integrations, for example M-Pesa checkout via Paybill, a WhatsApp button, a booking request form, a newsletter sign-up.
• Who provides content, and in what format and by when.
• The number of design revision rounds.
• Browsers and devices the site will be tested on.
• What is explicitly not included, such as copywriting, logo design or product data entry.

The exclusions list is underrated. It is much easier to agree that photography is out of scope before work begins than to argue about it later.

Sample wording: "The Developer will design and build the website described in Schedule A (pages, features and integrations). Any work not listed in Schedule A will be quoted separately and will only begin after the Client approves that quote in writing."

Timelines, dependencies and delays caused by the client

A timeline clause should give dates for each phase: design, build, testing, launch. Just as important, it should list what the supplier needs from you and by when. Typical dependencies are your logo files, page content, photos, M-Pesa account details and feedback on designs.

Be realistic. Most late projects are late because the client is busy running the business. The contract should say what happens then: usually the launch date moves by the same number of days. Some contracts also allow the supplier to pause a project that has been waiting on the client for a long period, such as 30 days, and to invoice for work done so far. That is reasonable, provided the clause works both ways and the supplier also commits to response times.

Sample wording: "Delivery dates assume the Client provides the items in Schedule B by the dates shown. Where the Client is late, delivery dates move by an equal number of working days."

Payment milestones and what triggers each one

The payment clause should list each instalment, the amount, and the event that triggers it. "50% now, 50% later" is not enough. "Later" should be a specific, checkable event.

The percentages are only an illustration; what matters is that each payment follows something visible. The clause should also state whether amounts are before or after 16% VAT, the payment method, and how long invoices may remain unpaid. We look at fair structures in more depth in website deposits and milestone payments.

Ownership of code, design, content and accounts

This is the clause that prevents the "designer disappeared with my site" problem, so read it slowly. Split ownership into four parts:

1. Accounts. The domain name and the hosting account should be registered in the client's name and email from the start. The contract should say so.
2. Your materials. Your logo, text, photos and customer data are yours throughout. The developer gets permission to use them for the project, nothing more.
3. The finished website. Design and custom code usually transfer to the client on full payment. Some firms keep the right to reuse general code libraries they wrote before your project, which is normal, while you get a permanent licence to use them.
4. Third-party items. Premium themes, plugins and fonts are licensed, not owned. The contract should say whose name the licence is in and who pays the renewal.

Add a portfolio clause too, if you care about it: many developers want to show your site in their portfolio, which is fine unless the project is confidential.

For a deeper look at each of these, including what to do when a developer refuses to hand over access, read who owns your website: domain, code and content.

Acceptance testing and warranty period

Acceptance is the formal moment you agree the work is done. The clause should say:

• How long you have to test the staging site, for example five working days.
• That you will send defects in a single written list.
• How quickly the developer will fix them.
• That acceptance is confirmed in writing, and what happens if you say nothing at all (some contracts treat silence after the testing window as acceptance, which is fair if the window is reasonable).

The warranty clause covers the period after acceptance. Any defect in the agreed scope, such as a broken form or a layout that fails on a common phone, is fixed at no charge. Thirty to ninety days is common. Note what the warranty does not cover: new features, content changes, or problems caused by someone else editing the site.

Sample wording: "For 60 days after acceptance, the Developer will correct, at no charge, any failure of the website to work as described in Schedule A."

Support, hosting and personal data

Three smaller clauses round out a sound agreement. They are short, but leaving them out causes friction a year after launch.

Ongoing support

Once the warranty ends, who looks after the site? Either the contract points to a separate support agreement, or it states plainly that support is not included and will be billed per request. What you want to avoid is an unspoken assumption on your side that the developer will "just sort out" problems forever, at no cost, while the developer assumes the opposite.

Hosting and renewals

If the developer arranges hosting, the contract should say who the account belongs to, who receives renewal reminders and who pays. An expired domain takes your website and your business email offline at the same moment, usually on a busy Monday.

Personal data and confidentiality

If the site collects customer details, or the developer will see your customer lists, add a clause on confidentiality and data handling. Under the Data Protection Act, 2019 your business remains responsible for personal data it collects, and the Office of the Data Protection Commissioner (odpc.go.ke) publishes guidance on what that means. A simple clause requiring the developer to keep data confidential, use it only for the project and return or delete it at the end is a sensible minimum.

Termination and handover if things go wrong

Nobody likes planning for a breakup, but this clause is what saves you if a project stalls. It should cover:

• How either side can end the contract, usually by written notice, and on what grounds.
• Payment for work done. If you cancel, you pay for completed milestones. If the developer abandons the work, they refund money for milestones not delivered.
• Handover. Within a fixed number of days, the developer hands over all logins, files, design sources and content in their possession, for the work you have paid for.
• Disputes. A first step of talking it through, then mediation or another agreed route before court.

For bigger builds, especially custom systems, the handover clause should also mention documentation and the database. Our system development projects include this as standard because a system without documentation is hard for anyone else to maintain.

A one-page contract checklist

Hold the supplier's agreement next to this list. Every line should have a clear answer.

• Scope schedule with pages, features, integrations and exclusions
• Content responsibilities and deadlines
• Phase dates and client dependencies
• Payment amounts, triggers, VAT treatment and method
• Domain and hosting in the client's name
• Ownership of finished work on full payment
• Third-party licence list and renewal responsibility
• Acceptance testing window and process
• Warranty length and coverage
• Support terms after the warranty
• Termination, refunds and handover
• Data protection: how any personal data you share will be handled, in line with the Data Protection Act, 2019
• Signatures, names and dates from both sides

If a clause is missing, ask for it to be added. A good supplier will not mind, and most will already have it somewhere.

Getting it in writing with Edgecom

If you are commissioning a site or system and want these points settled before any money changes hands, we are glad to work through the checklist with you. See how we approach projects on our web development page, or contact us and ask for our terms to read before you commit.