Blog — 2026-08-07
By Emad Yahya — web developer & IT systems engineer, Dubai
Choose WordPress when the website's main job is publishing content that non-technical people update often, and when the design fits patterns thousands of sites already use. Choose a custom-coded site when performance is a competitive advantage, when the experience is unusual enough that no theme expresses it, when the site has to talk to your other systems, or when owning every line of it matters. Most business websites are genuinely in the first category. The mistake is assuming yours is in the second because it feels more serious — or assuming it is in the first because it looks cheaper.
I'm Emad Yahya, a web developer in Dubai, and I build custom-coded sites. LKYOOB and UNHID are React and TypeScript — no WordPress, no theme, no page builder — THE GROE is custom-coded for the same reasons, and this bilingual site is custom too. So take the disclosure seriously: I have a commercial interest in one of these answers. That is precisely why this comparison is written to talk you out of a custom build whenever WordPress is the right call.
WordPress wins when the content changes more often than the design does, and when the people changing it are not developers.
That describes a large share of business websites honestly. If your site is mostly pages and posts, if someone in marketing needs to publish without filing a ticket, and if the design fits patterns that already exist, WordPress is doing exactly the job it was built for. The admin panel is familiar to most people who have worked in marketing, and the hiring pool is deep — in Dubai it is typically easier to staff a WordPress handover than a handover of unfamiliar code.
The plugin ecosystem is the other real advantage. Contact forms, multilingual content, ecommerce, SEO metadata, bookings — for standard needs someone has already solved it, and you are configuring rather than commissioning. On budget and timeline, a well-chosen theme configured properly is typically the fastest route to a working, editable site.
So here is the uncomfortable version: if a good theme already expresses your brand and your team's real need is publishing, a custom build is mostly ego. I say that as someone who builds custom for a living.
Custom wins in four situations, and they are more specific than "we want something unique".
A fifth case matters in this market in particular: proper bilingual English and Arabic. Arabic done as an afterthought is an English layout mirrored, with machine-translated labels and numbers sitting awkwardly against text running the other way. Doing it properly is a decision made at the start of the build, not bolted on at the end. This site is bilingual for that reason, and I write the Arabic myself.
On timelines for custom work, from my own delivery: a landing page takes 1–2 weeks, a brand or company site 2–4 weeks, and a custom platform 4–8 weeks depending on features.
Not money so much as attention — and attention is the resource small businesses run out of first.
A typical WordPress site accumulates a dozen or more plugins from a dozen different authors, each on its own release schedule, plus a theme and the core platform. Updates arrive constantly. Most are routine, some close security holes, and occasionally one shifts a layout or breaks a form in a way nobody notices until a customer mentions it. The realistic operating model is: update on a schedule, on a staging copy, with someone checking the important pages afterwards.
The sharper risk is abandonment. A plugin whose author stops maintaining it does not announce itself — it simply stops receiving fixes, and at some point it becomes something you must replace rather than update. Because WordPress is so widely deployed, it is typically a bigger target than niche platforms, and reported vulnerabilities usually sit in plugins and themes rather than in core. Which is another way of saying the risk usually enters through what you added, not through what you started with.
None of that makes WordPress a bad choice. It makes maintenance a line item you plan rather than discover. And custom sites are not maintenance-free either — dependencies, hosting, certificates and the occasional framework upgrade all still need attention. The honest difference is the number of moving parts and who controls them.
Not inherently — but it is much easier to make slow.
A lean WordPress site on decent hosting, with sensible caching and optimised images, can be genuinely fast. What is typically slow is the accumulated stack: a page builder, a slider, half a dozen plugins each loading their own CSS and JavaScript on every page, and an image library nobody ever compressed. Each addition felt small. The total is what the visitor waits for.
Custom code gives you control by default, which is not the same thing as speed. A carelessly built custom site is slower than a disciplined WordPress one. The platform guarantees nothing; the discipline does. What custom gives you is that nothing loads unless you decided it should — and when performance is the point of the project, that difference compounds across every page.
Treat page speed as a business concern rather than a scoreboard. Core Web Vitals are typically one input among many for search engines, but a slow site loses visitors regardless of what any algorithm thinks about it.
Both can rank well, and neither wins automatically — the platform is not the variable that decides it.
Search engines and AI assistants care about the same things either way: whether the page can be crawled and rendered, how fast it loads, whether the content actually answers the question, whether structured data explains what the page is, and whether credible sources elsewhere corroborate you. None of that belongs to one platform.
WordPress's advantage is that plugins handle sitemaps, metadata and schema without a developer, which keeps the basics from being neglected. Custom's advantage is exact control over what the page outputs — hand-written JSON-LD, a curated llms.txt, and HTML that exists before any JavaScript runs. This site prerenders every page to static HTML for precisely that reason.
Which points at the real risk of going custom badly: a site that renders only in the browser can look close to empty to crawlers that do not reliably execute JavaScript. If you commission a custom build, make server-rendered or prerendered HTML a written requirement rather than an assumption.
The content is the easy part. The URLs are where migrations go wrong.
Whichever direction you move, the work has the same shape: inventory every existing page, map each old URL to its new one, and put a permanent redirect on every single one — including the pages you are retiring. Then move the media with its alt text, rebuild the forms and confirm where submissions go, reinstall analytics and any advertising pixels, and replace whatever functionality a plugin used to provide.
Run the new site on a staging domain first, walk the redirect map end to end, then switch DNS. Expect a short wobble in rankings after any migration regardless of platform — a complete redirect map is what keeps it short rather than permanent.
Answer these six honestly and the decision usually makes itself.
Mostly leaning one way on the first three and WordPress is probably your answer. Mostly the other way and custom starts paying for itself. This is really the website-shaped version of a bigger question — whether to build or buy any business system — which I have written about separately.
If you would rather not guess, send me what you have now and what you want it to do. You get a straight recommendation and a fixed written quote within 24 hours, and if the answer is "stay on WordPress and fix the hosting", I will tell you that instead.
No. WordPress sites rank perfectly well, and its plugin ecosystem makes the basics — sitemaps, metadata, structured data — easy to get right without a developer. What hurts SEO is a bloated plugin stack, unoptimised images and slow hosting. Those are choices, not consequences of the platform.
It usually has a smaller attack surface, because there are fewer third-party components and it is not a mass-market target. That is not the same as being secure. A custom site with neglected dependencies, weak hosting or a sloppy contact form is a real risk. Security follows maintenance discipline far more than it follows platform choice.
Only if it was built for that. Custom sites can include an admin panel or a headless CMS for the sections that genuinely change, and it is worth specifying which sections those are up front. If the site is largely static brand content that changes a few times a year, many owners prefer to skip the editor entirely and send changes to the developer. Decide which you want before the build, not after.
From my own delivery times: a landing page takes 1–2 weeks, a brand or company site 2–4 weeks, and a custom platform 4–8 weeks depending on features. WordPress on a configured theme is typically faster than all of those, which is a perfectly legitimate reason to choose it.
Yes, if the migration is planned. Map every old URL to a new one, apply permanent redirects to all of them, keep the content and its structure intact, and stage the new site before switching DNS. A short dip after any migration is normal; a lasting one usually means the redirect map was incomplete.
It depends on scope rather than platform — a simple site either way is a smaller project than a bilingual brand site or a website wired into a CRM. Compare the whole picture rather than the build alone: theme and plugin licences, hosting, and the maintenance routine each option needs. Send me your requirements and you get a fixed written quote within 24 hours.
Custom software vs off-the-shelf for UAE businesses · Freelance Web Developer in Dubai · Website Maintenance in Dubai · Luxury Website Developer in Dubai · SEO & AI Visibility (GEO) Services in Dubai