WordPress
- Log in
- Edit page
- Publish
An admin panel. Anyone can learn it.
Cloudflare Workers
- git commit
- deploy
- live site
A repository. Someone has to know it.
This website runs on Cloudflare Workers. WordPress was the obvious alternative, and the case for it is stronger than people in our line of work usually admit, which is why the decision took longer than it looks.
Here is the whole reasoning, including the parts that argue against what we chose. If you're deciding the same thing for your own business, the useful bit is probably not our answer. It's the question we used to get there.
The decision nobody explains to the person paying for it
Most business owners never get told what their site is built on until something goes wrong. The developer picks, the site launches, and the owner discovers the consequences a year later, usually as a bill or a broken page. Then it's expensive to change.
WordPress is the default for good reasons. It's been around long enough that almost every problem has already been solved by somebody. There's an admin panel your staff can learn in an afternoon. Its plugin system is built precisely so the software can be extended without touching its core, which is why there's something ready-made for booking, forms, shops, memberships and most things in between. If you hire someone in Nairobi to work on it next year, they will know it.
The trade is that all of that arrives as a system somebody now has to maintain. Plugins update, sometimes against each other. The site needs hosting that stays fast under load. WordPress's own hardening guide is candid about it, describing security as risk reduction rather than risk elimination, split between the host's infrastructure and the application you install on it. That's true of any stack. The difference is how much of it lands on you.
What we actually weighed
Three questions decided it for us.
Who is going to run this site in a year? For our own site, the honest answer was us, and we are comfortable in a code editor. That single fact removes most of WordPress's advantage. The admin panel is worth a lot when the person publishing is not technical. It's worth much less when they are.
What does this site have to do? Ours needs to load fast on a phone on mobile data, take enquiries reliably, book calls, and publish articles. Nothing on that list needs a plugin ecosystem. A shop with a thousand products, or a membership site, would have changed the answer.
What breaks, and who notices? A site with fewer moving parts has fewer things that can fail quietly. That mattered more to us than any speed benchmark, because the failure we actually feared was an enquiry going missing.
Notice that none of the three asks which platform is better. That question has no answer, because platforms don't solve a business problem on their own. They offer different trade-offs around the same problem, and the useful question is which set of trade-offs fits the business doing the choosing.
What we run, in plain terms
The site is a Next.js application deployed to Cloudflare's network. Workers run application code across that network rather than on a server you rent in one city, and by default a Worker runs in a data centre close to where the request arrives. That helps with the first hop, and it doesn't mean every part of a page is assembled next door to the reader. Anyone promising you that is overselling it.
Enquiries are stored in Cloudflare D1, a SQL database, and a notification email reaches us through Resend. Keeping those separate is the point: the database holds a permanent record rather than the enquiry existing only as an email in somebody's inbox. Each step is best-effort in our code, so if the email fails the enquiry is still stored, if the write fails the email still goes, and the visitor only sees an error when both fail. Contact forms are the one part of a business website that must not fail quietly.
| Database | Notification | What the visitor sees |
|---|---|---|
| Written | Sent | Confirmation |
| Written | Failed | Confirmation |
| Failed | Sent | Confirmation |
| Failed | Failed | An error |
The form is protected by Turnstile, Cloudflare's alternative to a CAPTCHA, which checks for bots without making anyone identify traffic lights. API keys are stored as secrets with Cloudflare rather than written into any file we commit.
What it cost us
Four things, and none of them are small.
There is no admin panel. Publishing this post meant adding a file to a code repository. For us that's faster than logging into a dashboard. For a business owner who wants to change their opening hours on a Sunday evening, it's a genuine barrier, and pretending otherwise would be dishonest.
Nothing comes ready-made. Booking, the contact form, spam protection and email were all wired up rather than installed. In WordPress most of that is a plugin and an afternoon. That gap is a real cost and it shows up in the build price.
We had to design around how the platform stores things. A Worker doesn't sit on a normal server disk the way WordPress does, so we don't keep the articles as files to be opened and converted while a visitor waits. Every article on this blog is compiled into data when the site is built instead. The result is fast and it's what we wanted, but it's a decision we had to make rather than a default we inherited.
Fewer people can pick it up. If you needed someone other than us to work on this site, the pool of developers in Kenya who know WordPress is far larger than the pool who know this stack. That is the strongest argument against our choice and we don't have a rebuttal for it. We have a mitigation: the whole site lives in a repository the owner controls, so nobody is locked to us by access.
When WordPress is the better answer
If any of these describe you, we would say so rather than sell you something else.
Your team needs to edit pages regularly without asking anyone. You want a shop with real inventory, variants and payment options. You need a specific integration that already exists as a WordPress plugin and would otherwise be built from scratch. You want the freedom to hand the site to any developer in the country and have them understand it on day one.
There's no single right stack, and the deciding factor is usually not technical. It's who will be running the site a year from now, and how comfortable that person is.
How to decide for your own business
- Answer the year-from-now question first. Write down who will actually update the site, and how technical they are. That one answer eliminates most options before you compare features.
- List what the site must do, not what it could do. Booking, a shop, a members area and a blog are each a different size of job. A brochure site pretending it might one day be a shop gets built badly for both.
- Ask any provider what happens if you leave. Where does the site live, whose account owns the domain, and can you take it with you? A stack you cannot exit is worse than a stack you don't like.
- Ask what the running costs are, in total, per year. Hosting, domain, plugin licences, maintenance. The build price is the part people compare and rarely the part that hurts.
- Ignore anyone who tells you their choice is the only serious one. Including us.
Frequently asked questions
Is Cloudflare faster than WordPress?
The stack matters less than how the site is built. A well-built WordPress site on decent hosting will beat a badly built site on any platform, and we'd rather you took that away than a preference for our choice. What Cloudflare changes is the starting point, since code runs across its network rather than in one fixed location. That helps most on mobile connections and for visitors far from wherever your server happens to sit. It is not a substitute for building the site properly.
Can I edit a site like this myself?
Text and images, yes, once you're shown how the publishing flow works. But you should assume it will be less convenient than a WordPress dashboard. If editing the site yourself, frequently, without asking anyone, is high on your list, say so before the build starts. It should change what gets built.
Is WordPress insecure?
No. WordPress is maintained seriously, and its own hardening guide answers this better than we could. Security there depends on keeping core, plugins, themes, passwords, file permissions and hosting maintained, shared between you and your host rather than handled by either alone. None of that is exotic. It just has to be somebody's job, with a name against it, rather than an assumption.
What happens to my site if my developer disappears?
That's the question worth asking before you commit, whatever the stack. What matters is whether you own the domain, whether you have access to wherever the site lives, and whether the code sits somewhere you control. Get those three in writing.
Do you build every client site this way?
No, and it would be a poor sign if we did. The right stack depends on who runs the site afterwards and what it has to do. Our own site is the case where we were both the builder and the owner, which is the easiest version of the decision.
Sources and further reading
Everything above about our own build is first-hand. The platform claims come from the makers' own documentation, which is where we'd send you rather than to a summary of it.
- How Workers works and Workers placement, Cloudflare, for where application code actually runs.
- Cloudflare D1 and Turnstile, for the database and the bot check described above.
- Storing secrets for Workers, Cloudflare, which is explicit that sensitive values do not belong in a committed config file.
- Plugin Developer Handbook and the Hardening guide, WordPress.org, for how WordPress is extended and what securing it involves.
Where we can help
Business websites is one of our core services, and the year-from-now question above is one we ask at the start of every one, before anything gets chosen. Our website packages start at KES 60,000, and what you're paying for is largely the wiring described here: the parts that come free with a plugin have to be built and tested instead.
If you want the longer version of how this site came together, including the things that broke first, we built this website with the same tools we sell is the build log. For the case that a website should be judged on what it does rather than what it's made of, what a business website is actually for makes it properly.
If you're weighing this decision for your own business and would rather talk it through than guess, book a 30-minute discovery call. We'll tell you honestly when WordPress is the right answer for you, since that costs us nothing and getting it wrong costs you a rebuild.
