Updated for 2026
Web development is the construction of the website itself: the code, the content model, the performance characteristics and the measurement wired into it. A site converts when someone arrives, finds what they came for quickly, and can act on it without friction — and every one of those depends on decisions made during the build rather than on anything added afterwards.
Most sites that underperform were not badly designed. They were built without a performance budget, without a plan for a second language, and without anyone deciding in advance what a successful visit would look like.
TheBuzihub builds and rebuilds sites for businesses across the UAE, Saudi Arabia, Qatar, Kuwait, Bahrain and Oman, in English and Arabic. Whether a site is even the right surface is answered on the configure, buy or build assessment; this page assumes it is.
Request your free consultation — send us the URL and we will tell you what is costing you visitors before anyone discusses a redesign. Or call +971 54 545 3510.
The problem: launching and converting are different achievements
A site can be signed off, admired internally, and still lose most of the people who reach it. Four causes account for the great majority of it, and none is a design failure.
It is slow where the customer is. Performance is usually measured on a developer's laptop on office wifi. Real visitors are on phones, on mobile networks, sometimes far from the origin server. A site that feels instant in the studio can be several seconds to first content in practice, and that gap is where the visitors go.
The Arabic version was added rather than built. A right-to-left layout retrofitted onto a left-to-right build produces broken alignment, mirrored elements that should not mirror, and typography that renders as an afterthought — to precisely the audience it was added for.
Nobody decided what conversion means. If the site launched without defined actions and tracking to record them, there is no way to tell a good page from a bad one, and every subsequent improvement is a matter of opinion.
It cannot be changed without a developer. Where every copy edit is a ticket, pages stop being updated, and a site nobody maintains decays whether or not the code is sound.
Performance is a budget, not an adjective
"Fast" is not a specification. A build needs numbers agreed before it starts, and something that fails the build when they are exceeded.
The three that matter to visitors are how quickly the main content appears, how quickly the page responds to a tap, and whether the layout stays still while it loads. The third is the one users describe as "it moved when I tried to press it", and it is almost always caused by images without dimensions or fonts swapping late.
Four decisions do most of the work:
Images. Correctly sized, modern formats, explicit dimensions, and lazy loading below the fold. Oversized images remain the single largest cause of slow pages, years after that stopped being necessary.
Fonts. Subset, self-hosted, and limited in number. Arabic and Latin typefaces together can double the font payload if nobody is watching, and font loading is a common cause of both delay and layout shift.
Third-party scripts. Every tag, chat widget and pixel is someone else's code on your critical path. They accumulate quietly, and an audit of what is actually loading is often the fastest performance win available.
Where it renders. Server-rendered HTML for content that must be crawlable and fast on first view; client-side interactivity only where interaction genuinely needs it.
A performance budget enforced in the pipeline is worth more than any optimisation done afterwards, because it prevents the regression rather than discovering it.
Schedule your complimentary strategy session — book a build review and we will show you what your site is actually loading.
Building bilingual properly
This is the part most often underestimated, and the one where retrofitting is most expensive.
Direction is structural. Right-to-left is not a stylesheet toggle. Layout must use logical properties — start and end rather than left and right — so a single set of rules serves both directions. Retrofitting this means touching every component.
Some things do not mirror. Numerals, phone numbers, Latin brand names, media controls and progress indicators keep their direction inside a right-to-left page. Blanket mirroring produces a page that is technically flipped and practically wrong.
Typography differs. Arabic needs its own typeface selection, its own line height, and no letter-spacing — the script connects, so spacing it apart breaks the words. A layout tuned to Latin type will need genuine adjustment rather than a font substitution.
The content model has to expect it. Two languages means every translatable field exists twice, with a defined fallback and per-language URLs. Adding a second language to a single-language content model is a data migration, which is why we ask about it on day one even when the answer is "not yet".
Search treats them as a pair. Reciprocal hreflang between the two versions, self-referential canonicals, and separate sitemaps entries — the mechanics are on how bilingual sites get indexed correctly.
The identity side of the same problem — bilingual lockups, both scripts designed rather than converted — sits with the brand system the build implements.
What we build into every site
| Built in | Why it belongs in the build | Cost of adding it later |
|---|---|---|
| Analytics with defined events | otherwise there is no way to judge a page | historical data cannot be backfilled |
| Server-rendered HTML for content | crawlers and first-view speed | a rendering change, not a setting |
| Structured data | how machines identify the business and its pages | usually cheap, but often forgotten entirely |
| Logical-property layout | one rule set for both directions | every component touched |
| A content model editors can use | pages stay current | migration of live content |
| Redirect map at launch | old URLs keep their accumulated authority | traffic already lost, and recovery is slow |
| Accessible markup and contrast | reaches more people; overlaps with SEO | a retrofit across every template |
| Performance budget in the pipeline | prevents regression instead of finding it | a permanent cycle of re-optimisation |
The redirect row is the one that causes the most damage in practice. A relaunch that changes URL structure without a one-to-one map discards the standing of every page it moves, and the loss appears weeks later when the old addresses drop out of the index — long after everyone has congratulated each other on the launch.
Our architecture-first methodology
Define success before scoping. What a visitor should do, and how you will know. Everything else is downstream of this, and a site scoped without it is scoped by page count.
Model the content first. What types of content exist, what fields they have, how they relate, and which of them are translatable. This outlives every visual decision above it and is the expensive thing to change later.
Set the budget and the browser floor. Performance targets and the devices and connections they must be met on — decided with the client, based on who actually visits, not on what is convenient to test.
Build the hardest template first. Not the homepage. The template with the most complexity, in both directions, on a phone. It reveals the architectural problems while they are still cheap.
Wire measurement in as we build. Events defined and firing before launch, so week one produces data rather than questions.
Plan the launch, including the retreat. Redirect map, a staged cutover where possible, and a documented rollback. Launches go wrong; unplanned ones go wrong for longer.
Hand over a site your team can run. Editor training, a content model that does not require a developer for routine changes, and documentation for the parts that do.
Where the work is replacing an existing site rather than starting fresh, the sequence differs and the risks are mostly in migration — what a redesign has to preserve.
Accessibility, which is cheaper than it sounds
Accessible construction is usually treated as a compliance topic and postponed. Built in from the start it is close to free, and it improves the site for everyone rather than for a minority.
Most of it is unglamorous. Real headings in order rather than styled text. Form labels that are actually labels. Colour contrast that survives a phone in daylight. Keyboard access that works without a mouse. Alternative text on images that carry meaning, and none on the decorative ones. Focus states left visible instead of designed away.
Two things are worth knowing about the return. Search engines read the same structural markup that assistive technology does, so much of this work pays twice. And a site used in bright outdoor light on a mid-range phone — which describes a great many visits in this region — benefits from exactly the contrast and touch-target decisions accessibility asks for.
Retrofitting it later means revisiting every template, which is why it belongs in the build rather than in a remediation project.
After launch, the site is a system
A build is the beginning of the useful part. What follows is measurement and iteration, and it is a different discipline from construction.
The first thing to check is whether pages that receive traffic actually convert it: what to change when arrivals do not act, with campaign destinations treated separately because they answer to one intent — single-purpose landing pages. The measurement itself has to be trustworthy before any of that means anything: event definitions and collection.
Commerce adds requirements a brochure site never faces — catalogue structure, payment, fulfilment and the crawl budget a faceted navigation consumes: what a storefront build has to support. Internal systems behind the site are their own engagement: custom systems and the integration layer. And where the requirement is really an application rather than a site, the app-versus-mobile-site comparison is the honest place to start.
Increasingly, the other audience for a site is machines. Pages that state answers plainly and mark up their entities are the ones that get quoted — how answer engines read a site, and how spoken queries change the phrasing they match.
Content models at three different scales
TheBuzihub has built sites in the Gulf since 2018 and publishes 24 client case studies here, six of them technology builds.
A corporate site for a trading business and an enterprise site with a large content structure show the content-model work at two different scales, and a multi-tenant solution hub is the case where structure mattered more than presentation. Each is written up rather than summarised, which is the point of publishing them.
Website Build FAQ
How long does a website take to build?
A brochure site with a handful of templates is usually six to ten weeks. A larger site with a real content model, two languages and integrations runs three to five months. The variable that moves the date most is not development — it is content, which is almost always the critical path and is almost always underestimated at the start.
Should we use WordPress or something custom?
It depends on who will maintain it and what it must integrate with. A well-configured mainstream CMS is right for most content sites and cheaper to staff. Custom is warranted when the content model is genuinely unusual or the site is really an application. The wrong reason to go custom is that a platform feels unfashionable.
Can you add Arabic to our existing site later?
Sometimes, and how expensive it is depends on how the site was built. If the layout uses logical properties and the content model has translatable fields, it is straightforward. If neither is true, it means touching every component and migrating the content — which is frequently a rebuild wearing another name.
Will a new site improve our search rankings?
Only if it fixes something search was penalising, and it can easily make things worse. The two decisive factors are whether URLs change and whether the redirect map is complete. A faster, better-structured site helps; a relaunch that loses its redirects can cost months of accumulated standing.
Who hosts it, and who owns the domain?
You should own both, under your own billing, with our access granted rather than the other way round. Domains registered by an agency are a recurring source of disputes at exactly the moment when nobody wants one. We set this up in your name at the start and document where everything lives.
What does ongoing maintenance actually involve?
Security and dependency updates, backups that have been tested by restoring one, monitoring, and periodic performance checks as content accumulates. It is not optional: an unmaintained site is a security exposure. The compromised sites we are asked to recover are almost always running an out-of-date component that nobody had been made responsible for.
Do you design as well as build?
Yes, and we also build to someone else's design. Where design comes from elsewhere, we ask for the responsive behaviour and both text directions to be considered in it — a design supplied only as desktop, left-to-right comps means those decisions get made by developers, which is a poor place for them to be made.
How do you handle content migration from an old site?
By auditing it first and deciding what should survive. Most sites carry pages nobody has read in years, and moving them wholesale preserves clutter and costs money. We map old URLs to new ones for everything with traffic or links, redirect the rest deliberately, and confirm afterwards that nothing valuable now returns a 404.
Related Reading at TheBuzihub
- Deciding whether to build at all — configure, buy or build, before the brief.
- Replacing a site without losing what it earned — migration, redirects and the traffic at risk.
- Storefront-specific requirements — catalogue, payment and faceted navigation.
- Campaign destinations built for one intent — the other half of every paid click.
- Turning arrivals into enquiries — the discipline that starts where the build ends.
- Custom systems behind the site — portals, integrations and internal tools.
- How machines read what you publish — the second audience for every page.
- An enterprise build, published in full — content model at scale.
Measure the existing site before scoping a new one
Before a redesign is scoped, it is worth knowing which pages are working, which are slow, and where visitors leave.
Claim your free marketing audit of the existing site: real-device performance, whether the Arabic version holds up, what the measurement is actually recording, and which pages carry the traffic. Occasionally the answer is that four fixes would do most of what a rebuild would have done — and that is a better outcome for you than a project.
Talk to us · How we work · The full service range
Phone: +971 54 545 3510 Email:info@thebuzihub.comOffice hours: Monday to Friday 09:00–18:00, Saturday 09:00–13:00 (UAE time). Current hours are always on the contact page.