We’ve been called in to fix other people’s work more times than we’d like to count.
A school in Embu that paid KES 45,000 for a website that was never launched. A tour company in Nairobi whose developer disappeared three weeks before peak season with the admin credentials. A hardware shop in Thika that got handed a beautiful-looking site that couldn’t accept M-Pesa and had no way to add new products without calling the developer.
The Kenyan web development market has a talent problem — not a shortage of developers, but a shortage of accountability. Anyone with a laptop and a Canva account can call themselves a web developer today, and business owners with no technical background have no reliable way to tell the difference between someone who’ll deliver and someone who’ll disappear.
This article is our attempt to fix that. These are the ten mistakes we see Kenyan businesses make when hiring a web developer — drawn from real client experiences, real rescue jobs, and real conversations with frustrated business owners across the country.
Mistake #1: Hiring based on price alone
The most common mistake, by far.
A business owner gets three quotes: KES 8,000, KES 35,000, and KES 80,000. They go with the KES 8,000 developer because “it’s just a website.” Three months later, they’re back in the market looking for someone to rescue the project — now paying KES 80,000 to fix what the KES 8,000 developer broke.
We’re not saying expensive always means better. We’ve seen overpriced work that was mediocre. But below a certain threshold — and in Kenya that threshold for a proper business website is roughly KES 20,000 to 25,000 — there is no sustainable business model for the developer. They are either cutting corners you can’t see yet, using someone else’s code without a licence, or planning to abandon the project when something better comes along.
What to look for instead of price:
When comparing quotes, ask each developer to break down what the price includes. What hosting are they recommending? Are they building on WordPress, custom PHP, a drag-and-drop builder? What does post-launch support look like? A developer who can answer those questions clearly is one who has thought through the project. One who just names a number hasn’t.
Price is the last thing you should be comparing. Capability and process are first.
Mistake #2: Proceeding without a written contract
Kenya runs largely on relationships and trust — which is a wonderful thing in most contexts, and a catastrophic thing when a project goes wrong.
We’ve had clients come to us after paying developers they knew personally — church members, university friends, cousins — with nothing in writing. When the work stalled, there was no contract to reference, no agreed milestone schedule, no clarity on what was and wasn’t in scope. The relationship soured, the money was gone, and the website was half-finished.
A proper contract doesn’t mean you distrust the developer. It means both parties have clarity on what success looks like. At minimum, your contract should specify: the full scope of work, the payment schedule tied to deliverables, the timeline with dates, who owns what at each stage, what happens if deadlines are missed, and who holds credentials for hosting and domain.
If a developer is reluctant to sign anything in writing, that reluctance is itself important information.
Mistake #3: Not verifying the portfolio properly
Showing a portfolio is easy. Building a portfolio is harder. The gap between those two things is where many Kenyan business owners get misled.
A developer can show you screenshots of beautiful websites they didn’t build, Behance mockups that were never developed into real sites, or live URLs for sites that run on a template they simply uploaded. None of that tells you whether they can actually build and deploy a functional, custom website.
How to verify a portfolio properly:
Ask for the live URLs of three to five websites they built. Visit them on your phone — not just a desktop. Check load speed. Try to find the admin panel (usually yoursite.com/wp-admin for WordPress) and note whether it exists. Ask what specific problems came up during each project and how they were solved. A developer who can tell you “we had trouble with the M-Pesa callback URL because the client’s hosting blocked port 443 — here’s how we fixed it” is someone who actually did the work.
Also ask directly: did you build this alone, or with a team? There’s nothing wrong with team-based development — but you want to know what the individual you’re hiring actually contributed.
Mistake #4: Not agreeing on a timeline upfront
“I’ll have it done in a few weeks” is not a timeline. It’s a placeholder.
Vague timelines are one of the primary mechanisms through which web development projects drag on indefinitely in Kenya. Without a specific deadline, there’s no point at which either party can formally say the project is late. The developer always has a reason — another client, load shedding, a sick relative — and the business owner has no contractual basis to push back.
A properly scoped project should have a milestone schedule that looks something like this: discovery and wireframe approval by a specific date, design mockup approval, development of core functionality, M-Pesa and third-party integration, testing and review period, final delivery and launch. Each milestone should have a date and a payment attached to it.
Specific dates create accountability. “A few weeks” creates nothing.
Mistake #5: Paying 100% of the project fee upfront
This one funds the stories that get told at business networking events.
Paying everything upfront removes almost all leverage you have as a client. If the developer runs into problems, gets distracted, or simply decides to move on, you have no financial mechanism to incentivise completion. And recovering money from an individual developer in Kenya — without a contract, without a receipt, without any paper trail — is practically impossible.
A healthy payment structure ties money to delivery. A common and fair structure we use is: 30% to start the project, 40% on approval of the design and core functionality, and 30% on final delivery and launch. Some projects justify different splits, but the principle holds — the developer gets paid as work is delivered and approved, not before.
Never pay more than 50% upfront for any web project, regardless of how convincing the sales pitch is.
Milestone-based payments protect both you and a developer who delivers on time
Mistake #6: Letting the developer choose the platform without understanding the implications
“I’ll build it on Shopify — it’s easier” sounds fine until you realise you’re paying $80/month in subscriptions, your customers can’t pay with M-Pesa at checkout, and adding a new product type requires a $40/month app.
Many Kenyan developers recommend platforms based on what they know how to build quickly, not what’s best for your business long-term. A developer who only knows Shopify will recommend Shopify. A developer who only knows WordPress will recommend WordPress. The recommendation is often about their skill set, not your needs. We have a detailed blog about this in https://alphatechdevelopers.co.ke/wordpress-vs-shopify-custom-development-kenya/
Before any platform decision is made, you should understand: what are the monthly ongoing costs? What payment methods does it support natively? Can we add features without paying per-feature app subscriptions? If we ever want to move to a different platform, how painful is that migration?
A developer who gets defensive or impatient when you ask these questions is not the right developer for your business.
Mistake #7: Allowing the developer to register hosting and domain in their own name
This is the single most dangerous mistake on this list — and it’s shockingly common.
When a developer registers your domain (say, yourbusiness.co.ke) under their own account at a registrar, or signs up for hosting using their email address and payment method, they own those assets — not you. If the relationship sours, they can hold your website hostage. We have personally spoken to business owners who were paying a former developer a monthly “maintenance fee” not because maintenance was being done, but because the developer controlled the domain renewal and the client was terrified of losing their web address.
The fix is simple but must be insisted upon from day one: your domain and hosting accounts must be registered in your business name, using your business email address, with your payment method on file. The developer is given access to those accounts to do their work. When the project ends, you revoke that access. Your website, your domain, your hosting — all stay with you.
If a developer insists on handling registration themselves, ask very specifically why. The only acceptable answers involve billing convenience — and even then, you should be added as the account owner immediately.
Mistake #8: Agreeing to a vague scope of work
“A full website with all features” is not a scope. It is an invitation to a dispute.
Scope defines the boundaries of what a developer is committing to deliver. Without a clear scope, every additional page, every additional feature, every revision beyond the first becomes an argument about whether it was “included” or an extra. Developers who work with vague scopes — intentionally or not — almost always end up charging for things the client assumed were covered.
A proper scope of work lists: the number of pages, the specific functionality required (contact form, M-Pesa payment, user login, booking calendar, product catalogue — whatever applies), the specific third-party integrations needed, the number of revision rounds included, and what is explicitly out of scope.
Anything not in the scope document is not in the project. Anything you add after signing is a change order, with a cost and timeline attached. That’s how professional engagements work — and it protects both parties.
Mistake #9: Not getting training on how to manage the website
The website is live. It looks great. The developer hands over the link. You ask how to add a new blog post, and they spend twenty minutes doing it for you while you watch.
That is not a handover. That is the beginning of a dependency.
A business website that you cannot manage yourself — or that requires a technical person for even basic updates — is a liability, not an asset. You’ll either pay the developer every time you need to make a change, or you’ll let the site go stale because updating it feels like too much trouble. Neither outcome is good for your business.
Any good developer should include a basic training session as part of the project. That session should cover: how to add and edit pages, how to publish blog posts, how to update products or services, how to view basic analytics, and who to call if something breaks. Ideally this is recorded so you can refer back to it.
If a developer doesn’t offer this, ask for it explicitly. If they charge extra for it, factor that into your evaluation of the overall relationship.
Mistake #10: Launching without a maintenance plan
A website is not a one-time project. It is a piece of running software that requires ongoing care.
WordPress core, themes, and plugins release updates constantly. Some updates are security patches — if you ignore them, you leave your site vulnerable to exploits that are actively used in the wild. Others are compatibility updates — ignore those long enough and your site starts breaking in ways that are expensive to fix retroactively. SSL certificates expire. Hosting payments lapse. Domain renewals get missed.
We’ve been called in to fix sites that hadn’t been updated in two years and had been silently serving malware to visitors for months. The business owner had no idea. The SEO damage alone took six months to recover from.
Before your site launches, you should have a clear answer to: who is responsible for software updates? Who monitors uptime? Who handles backups and where are they stored? What happens if the site goes down on a Saturday?
If your developer offers a maintenance retainer, evaluate it seriously. If you’re managing it yourself, set calendar reminders for monthly plugin updates, quarterly theme reviews, and annual domain/hosting renewal checks. A neglected website is not just a technical problem — it’s a business risk.
The pattern behind all ten mistakes
Reading back through this list, there’s a thread running through all ten: the absence of clear agreements.
Most of these problems don’t come from malicious developers. Most come from projects where expectations were never formalised, ownership was never clarified, and both parties operated on assumptions that turned out to be different. The developer assumed revisions were limited. The client assumed revisions were unlimited. Nobody wrote it down.
The Kenyan business community has a strong culture of doing things on trust and goodwill — and that’s genuinely one of our strengths as a market. But trust without documentation is not trust. It’s optimism. And optimism is a poor substitute for a contract when a project starts going sideways.
What a professional hiring process actually looks like
Before you hire any web developer in Kenya, run through this checklist:
- Ask for three live website URLs — not screenshots, not mockups, live sites — and call one of their past clients directly. Ask how the experience was, whether the developer stuck to the timeline, and whether the client would hire them again. Three minutes on the phone with a real past client tells you more than any portfolio presentation.
- Get a written proposal that specifies the platform, the full list of pages and features, the payment schedule, the timeline with specific dates, and what post-launch support is included. If they won’t provide a written proposal, that’s your answer.
- Structure payment around milestones. Start with 30%, or more.
- Ask specifically how M-Pesa will be integrated. The developer should be able to explain the method — plugin, Daraja API, third-party gateway — without hesitation.
Working with Alphatech
We’ve written this article because we believe the Kenyan business community deserves better than the standard of web development it’s often getting. We’re not perfect, and we’ve made our own project management mistakes over the years. But we work from written proposals, we structure payments around deliverables, we register everything in the client’s name, we provide training at handover, and we’re available after launch.
If you’re currently evaluating developers for a project — or trying to rescue one that’s gone wrong — we’d be glad to talk. Visit us at alphatechdevelopers.co.ke or reach out directly.