How much does a website cost in Kenya?

"How much does a website cost in Kenya?" is the first question almost every business owner asks us, and the answer is a range, because a website is not one thing. A one-page site for a new salon and a content-managed site for an engineering firm are both "websites" and they cost very different amounts. Here is how the numbers break down in 2026, what moves them, and what to include in a development brief.

The realistic ranges

These are the planning ranges we use for a custom-built site in Nairobi, intended for a first budget. They assume original design and maintainable code. Confirm current pricing with any developer before committing.

Those bands overlap on purpose. A five-page site with one awkward integration can cost more than a twelve-page site with none. Page count is the number everyone asks about, and it is rarely the number that decides the price.

The running costs after launch

The build is a one-off. Running the site is not, and this is where budgets are most often short. Three line items, every year, for as long as the site exists:

• Domain: around KES 1,500 a year for a .co.ke or .com. Renew it on time. Letting a domain lapse is the most expensive small mistake on this list.
• Hosting: anywhere from nothing to about KES 15,000 a year. A brochure site on a modern platform can genuinely sit in a free tier. A store with real traffic will not.
• Maintenance: optional, and the item most often skipped. Dependencies age, form delivery can break, and a contact page can stop working without anyone noticing until an enquiry is missed.

So the five-year cost of a KES 60,000 site is not KES 60,000. With a domain and modest hosting it is closer to KES 75,000 before any maintenance, and that is the fair number to compare against the alternatives.

What moves the price

Four things, roughly in order of impact.

• Content readiness. If your text, photos, and service descriptions exist and are approved, the build runs. If they do not, someone has to write them, and that someone bills for it. Having content ready is the cheapest way to lower a quote.
• Custom design versus a theme. A design built around your brand costs more than a theme, and usually earns it back in credibility. That matters most if you compete on trust rather than price.
• Features. A booking system, an M-Pesa checkout, or a member login each adds development time, and each adds one more thing that can break later.
• Structure and speed. The technical groundwork costs a little more once and saves a rebuild later.

A worked budget

An illustrative example, not a quotation. Suppose you run a three-branch clinic and want a site that brings in booking enquiries. Work it through:

Whether that was a good purchase depends on what one customer is worth. Suppose the clinic charges KES 3,000 a consultation. At four additional bookings a month attributable to the site, the first year returns KES 144,000; at one a month, KES 36,000, and payback takes around three years. Attribution is the difficult part of that calculation, because a website is one of several things influencing whether someone books, so treat the result as a planning estimate rather than a forecast. Work out what one customer is worth to you before asking anyone for a quote.

Two ways the budget gets spent twice

The first is paying a premium for a build with no handover, leaving a site nobody in the business can edit and nobody available to ask. The second is paying very little for a template that is slow, generic, and impractical to change. Both can end in a rebuild inside a year, at which point the cost was the first build plus the second. Asking what happens after launch, and who holds the accounts, addresses both.

A related cost is capability that is never used. A content-management system is worth paying for where someone will post to it; where the content is fixed, it adds build cost and maintenance for no return. Decide who will update the site, and how often, before it is scoped in.

What to have ready before you brief anyone

Content is the most common cause of delay on a website build, and the least visible, because nobody is working while everyone is waiting. A build can finish in three weeks and launch in nine because the remaining page text was still being written. Gathering these before the project starts usually lowers both the cost and the timeline:

• Your services, written out, one short paragraph each. Rough is fine. A developer can edit prose; they cannot invent what you do.
• Prices, or a decision that prices are on request. Deciding this late changes page structure, not just words.
• Photos you own. A real photo of your premises, your team, or your work beats stock, and it is the one thing a competitor cannot copy.
• Your logo as a vector file (.svg, .ai, or .eps), not a JPEG pulled off an old brochure.
• Access to your domain registrar, meaning working credentials rather than the name of whoever registered it several years ago.
• The three sites you like and the reason why, which is more useful than the ones you dislike.

Domain access is the item that most often causes a delay. If nobody in the business can sign in to the registrar, budget an extra week for recovery and start the process on day one rather than in the week of launch.

How to brief a developer

Tell the developer three things: what the site is for, who it is for, and what success looks like as a number you already track. "More enquiries" is not measurable. "Twenty booking enquiries a month, up from six" is. Scoping against a specific number makes it possible to say which parts of the build are likely to affect it and which are not.

Then ask for a fixed scope in writing, with the exclusions listed. "It depends" is a reasonable position on a first call. A quote that never becomes specific usually means the scope was never settled, and unsettled scope tends to return later as a change request.

• Ask what happens after launch, and who fixes a broken form in month four.
• Ask whether you own the code, the domain, and the hosting accounts. The answer should be yes to all three.
• Ask to see the site on your own phone, on mobile data, before you sign anything off.
• Ask what is deliberately not included. A developer who can answer that has thought about scope.

If a five-page site meets the requirement, that is what the quote should cover. A smaller scope is a normal outcome of a scoping conversation rather than a sign that something was missed.