WordPress or a Custom Website? How Kenyan Businesses Should Decide

The honest short answer

If you are publishing a lot of text — news, blogs, resources, a directory of products — and your team will update it constantly without a developer, WordPress is usually the right call. It is mature, well supported in Kenya, and a Nairobi developer can hand it over without drama.

If the website is a product in itself — a booking engine, a portal, a dashboard, an M-Pesa checkout with real business logic behind it — a custom build is usually the better home. WordPress can be bent into that shape, but you end up maintaining a stack of plugins that were never designed to work together.

There is a third case that matters more than people expect: the site is ordinary in function, but you care how it looks, how fast it loads, and how freely it can be changed later. That is where custom code often wins as well — because reaching a genuinely polished, distinctive result on WordPress usually means buying a theme, a page builder and a set of plugins, then accepting the limits of all three.

What WordPress gives you

WordPress powers a large share of the web for good reasons. It is not a compromise so much as a sensible default for content.

• ✓Lower upfront cost for a standard business or blog site.
• ✓Familiar editing interface that non-technical staff can learn quickly.
• ✓A huge ecosystem of plugins, themes and Kenyan developers who know it.
• ✓Fast to launch when your content is already written.

What a custom build gives you

A custom site is built around your business rather than around a template. That pays off most when your requirements are specific, when your site is meant to do something rather than just say something, or when speed on a Kenyan mobile connection decides whether people stay.

The difference is not about elegance. It is about who sets the ceiling on what your website can become — and whether you keep paying for the privilege of reaching it.

• ✓No ceiling set by someone else: if you need a feature, it is built for you, instead of being approximated by the nearest plugin that happens to exist.
• ✓Layouts and interactions are not limited to what a theme or page builder can express. If the design needs it, the code can do it.
• ✓Only the code you need, which usually means a faster, lighter site on mobile data.
• ✓Fewer moving parts to patch: nothing breaks because an unrelated plugin pushed an update, and there is a smaller attack surface.
• ✓No per-feature subscriptions. The capabilities are yours, not rented from a vendor every year.
• ✓Nothing depends on a page builder that may change direction. Page-builder layouts are stored in that builder’s own format, so leaving it later means rebuilding; standard code is not trapped that way.
• ✓Clean structure that is easier to optimise for search and to extend as your business changes.

The cost comparison nobody gives you

WordPress looks cheaper on day one, and for a simple brochure site it often is. The gap narrows as soon as you add the parts a respectable site actually needs — a premium theme or page builder, forms, SEO, caching, security and backup — because each of those is a separate product with its own price and its own renewal.

A custom build costs more upfront. Over three to five years, a lean custom site can be cheaper to run than a heavily plugin-loaded WordPress install, because there is less to update, less to break, and nothing being rented.

The subscription stack behind a "free" WordPress site

WordPress itself is free. A polished WordPress site is not, and the cost is rarely a one-off purchase. Beyond the simplest site, most projects end up with a paid theme or page builder plus extensions for the things the business actually needs — sold as annual, per-site subscriptions.

• ✓A premium theme or page builder, licensed per site and renewed every year.
• ✓Forms, SEO, caching, security and backup plugins — each with a free tier that stops short of what a serious site needs.
• ✓Every feature you add: bookings, memberships, e-commerce extensions, multi-currency, email marketing. Usually a separate purchase for each.
• ✓Typical premium plugins run from tens to a few hundred dollars per year, per site. Prices change, so check current pricing rather than trusting any blog post — including this one.

The plugin that almost does what you need

Money is not the only cost. Every subscription is also an update you must apply, a compatibility you must watch, and a possible conflict with another plugin. That is why plugin-heavy sites need maintenance in a way that lean ones do not.

More importantly, a plugin gives you the closest thing someone else decided to build, then asks you to bend your business around it. The real cost of the plugin that almost does what you need is the gap between it and your requirements, which you end up maintaining forever: a workaround now, a custom add-on later, a rebuild after that.

None of this makes premium plugins a waste of money. If a mature plugin already does exactly what you need — a contact form, a blog, a small shop — the subscription is far cheaper than paying a developer to rebuild it. The point is that the cost is recurring, the capability stops where that vendor’s roadmap stops, and none of it is yours to change.

Why Next.js sites usually load faster than WordPress

Once you decide to build custom, the framework decides much of your speed — and this is where Next.js earns its place. The advantage is not marketing; it comes from how each platform produces a page in the first place.

• ✓No PHP and no database on each request. A Next.js build pre-renders pages into finished HTML at build time, so the server hands over a ready file. WordPress assembles the page with PHP and queries MySQL on every visit, unless a full-page cache plugin steps in front of it.
• ✓The page ships only the code it needs. Next.js splits JavaScript per route, so someone reading your services page is not downloading the code for your blog. A typical WordPress build loads the theme, the page builder and plugin scripts across the whole site.
• ✓Static content needs no JavaScript at all. With React Server Components, text and layout arrive as HTML, so the browser paints the page instead of waiting on scripts — which is exactly what the Largest Contentful Paint metric measures.
• ✓No plugin script tax. Every plugin that adds a slider, pop-up, form or tracking snippet adds its own CSS and JavaScript, usually to every page. On a lean build there is nothing extra to add.
• ✓Caching is built into delivery rather than bolted on. Content-hashed asset filenames mean a visitor downloads your stylesheet and scripts once and never revalidates them again, while the HTML is served with no per-request work at all.
• ✓Images, fonts and third-party scripts are handled at build time by the framework rather than by plugins: correctly sized images, self-hosted fonts, and no jQuery loaded to support a theme.

Speed and hosting

A well-built WordPress site on good hosting can absolutely beat a badly built custom site. So the honest comparison is not "WordPress is slow" — it is this: on WordPress, speed is a feature you buy and maintain. On a coded build, it is where you start.

That difference shows up in the running costs as much as the loading times. A caching plugin, a CDN and a performance-tuned theme are subscriptions and updates you take on to reach the speed a lean custom build has from day one.

Whichever route you take, what matters is that images are compressed and correctly sized, caching is configured rather than hoped for, scripts are not imported for pages that never use them, and the hosting does not buckle under Kenyan mobile traffic.

You do not have to take a developer’s word for any of this, including ours. Open PageSpeed Insights and run two sites you are genuinely comparing — a current WordPress build and a coded one — then look at two numbers: Largest Contentful Paint on mobile, and server response time. Do it again on a phone on mobile data. It takes two minutes and settles the argument better than any blog post.

Security and updates

WordPress needs regular updates: core, themes, plugins. Skip them and your site becomes a target; update blindly and the occasional plugin release breaks a layout. That runs on a maintenance schedule.

Custom builds avoid third-party plugin churn, but they still need patching, dependency updates and monitoring. There is no such thing as a website that needs nothing after launch.

Who actually owns the website?

This is where most assumptions are wrong, so it is worth being precise: paying an invoice does not transfer ownership of the work. Under copyright law — in Kenya, the Copyright Act, Cap 130 — copyright in a work belongs to the author from the moment it is created, and it passes to someone else only by a written assignment. If your contract is silent, the developer or agency you paid generally still owns the copyright in the code and the design, and you hold whatever licence the contract implies.

That does not make them dishonest, and it does not mean the website is not yours to use. It means the answer to "what do I own?" is found in the contract rather than the invoice — which is why it should be settled before work starts, not discovered the week you try to leave.

Licensing rather than assigning is also a legitimate model. Agencies that build on reusable in-house frameworks often keep the copyright and grant the client a licence, in the same way WordPress itself is licensed rather than sold. The problem is never the model; it is only discovering the model after you have paid.

A working website is not the same as its source code

There are two different things a developer can hand over, and the difference decides how free you actually are.

• ✓A working website: the finished files that run on your hosting — the built HTML, CSS and JavaScript, or an installed WordPress site with its theme, plugins and content. This keeps the site online and lets you make surface edits.
• ✓The source code: the originals a developer edits — component and style files before they are compiled, the build configuration, any custom plugin or application code, and the database. This is what another developer needs in order to change how the site behaves, move it to a different host coherently, or rebuild part of it.
• ✓So handing over "a working site plus the build files" keeps the lights on, but it does not keep the site growing. If you might ever change how it works, hire a different developer, or migrate it, you want the source code — or a written, lasting right to obtain it.
• ✓On WordPress, "source" usually means the theme (including any child theme and custom code), the plugin list with versions, and a database export. On a custom build it means the code repository, the database, and the deployment configuration.

The WordPress lock-in nobody mentions: licences

WordPress is open source: the software is released under the GPL, and WordPress takes the position that themes and plugins are derivative works and inherit that licence. In practice, whoever holds the theme and plugin files is generally free to keep using and modifying them. On WordPress the code is rarely what locks you in.

The subscriptions are. Premium themes and plugins are usually sold as annual, per-site licences — you are buying updates, support and often a licence key that has to keep validating. Those belong to whoever bought them, and vendor terms frequently do not allow transferring them to a new owner. Stop renewing and the site keeps running, but it stops receiving security and compatibility updates, which is precisely the state that gets WordPress sites compromised. That is real lock-in, and it survives even when you own the files.

Custom code has its own dependency — someone has to maintain it — but this is a dependency you can name in advance: a repository you control, no per-feature subscriptions, and no vendor deciding whether your licence continues.

A handover checklist to put in writing

Work these into the agreement before you pay a deposit, so that leaving is boring rather than a negotiation.

• ✓Who owns the copyright, and when it passes — normally on final payment, in writing.
• ✓That you receive the source code (or a lasting written right to obtain it), the database, and the build files.
• ✓That the domain, DNS, hosting and business email are registered in your name, or transferred to it.
• ✓How you get administrative access to the website, hosting, analytics and search accounts when the relationship ends.
• ✓A list of third-party themes, plugins and services: what they cost, when they renew, and whose name the licence is in.
• ✓What migration support looks like if you move to another developer — and for how long it is provided.
• ✓That the content is yours to take: text, images, product data and customer records.

One caution before you rely on any of this

What is above is the general position, not legal advice, and the detail depends on your contract and where you operate. For a site that takes payments or holds personal data, have a lawyer read the clause rather than taking a blog post’s word for it.

Then pay attention to how the question is answered. A developer who sets out plainly what you keep, what you license and how you leave is the one you can safely hire; vagueness on this point is the signal worth acting on.

A simple way to decide

Picture the website in three years. If it will still be mostly pages, articles and product listings, choose WordPress and spend your budget on content and search optimisation. If it will be doing transactions, calculations, integrations or handling large amounts of data, choose a custom build and spend your budget on getting the structure right.

If you are genuinely unsure, ask a developer to argue both cases for your specific business — including the running costs. Be wary of anyone who has only one answer, whatever your requirements look like.

Next steps

Microstation builds both: WordPress and WooCommerce sites where content and speed to launch matter most, and custom Next.js websites and web applications where performance, integrations and M-Pesa payments are central. Our own website runs on that stack, so you can judge the speed for yourself before you hire us.

Book a free consultation and we will recommend the platform that fits your business — including when the cheaper option is the right one.