Headless CMS development · UAE
Most briefs that arrive asking for headless describe one website. Webzenia counts the surfaces the content has to reach first, and says plainly when a simpler build gets you there.
Get a straight answer on headlessWhen headless earns its cost
Headless CMS development separates the content from the thing that displays it. That is worth paying for when more than one thing displays it, and not before.
Arabic is a locale on the content model, not the English site translated into a second folder. Both versions carry their own structured content, render right to left, and publish from the same entry.
An app, a client login, or a screen in a branch or a showroom. Each reads the same content and presents it differently, and that is what a content API is actually for.
The one that does not count. A slow page is almost always the build rather than the CMS, and replacing the architecture to fix it buys a standing bill you will still be paying once the pages are fast.
Count the surfaces first
The number of places your content has to appear decides the architecture. Three answers are common here, and only two of them are worth the bill headless brings with it.
| One websiteOne site, one language, one team publishing | A website and ArabicTwo locales, carried on one content model | A website and a productA site, plus an app, a portal or a screen | |
|---|---|---|---|
| Where the content sits | Inside the pages, and moving it means rewriting them. | In one model, with a locale field on every content type. | In one model that every surface reads through the same API. |
| Adding the next one | A second build, and two copies of the content to keep in step. | The Arabic version publishes from the same entry as the English. | A new reader of the same API. The content itself does not move. |
| Who publishes | Whoever edits pages, in whatever the current CMS gives them. | One editor, switching locale, with both versions linked. | One editor for every surface, including the ones without pages. |
| What year two runs on | One CMS licence and one host. The bill you already have. | A content store with seats, and a front end of its own. | Two deploy surfaces, a seat bill, and a developer within reach. |
| What we would build | A better content model on a simpler stack, and we will say so. | Headless, because a real locale is a second surface. | Headless, with the second surface scoped in the same engagement. |
Most briefs that reach us asking for headless sit in the first column, and the honest answer there is a better content model on the stack this pillar builds on. Where the complaint is that the site is slow, that is a measurement job before it is an architecture one. Where visitors read the site and never enquire, the fix sits earlier in the page than the CMS does. We say which column you are in on the first call.
From the field · Headless briefs
Webzenia has worked with Gulf clients since 2018. Four things decide whether headless is the right build here, and none of them is the technology.
The word usually arrives with somebody: a developer, an agency pitching a rebuild, or a group standard set in another market. None is a bad reason to ask. Each is a bad reason to buy, until the surfaces are counted, and a Deira trading house on a DET mainland licence has one.
Both languages sit against the same content types, each with its own structured content, and the front end renders right to left per locale. That is a different mechanism from a theme loading a right-to-left stylesheet over a second copy of the site, and it is why the two versions cannot drift.
There is a content store on a licence with seats, and a front end deployed on its own. Between them sits code that only a developer changes. A traditional CMS bills for one of those. A Business Bay brokerage on a DET mainland licence budgets for all three, or borrows it from year two.
A DIFC fund, or a Hub71 SaaS company on an ADGM licence, sits under its own data-protection regime rather than the federal one, so where the content store lives can be a compliance answer rather than a preference. Headless lets you settle that separately from delivery speed.
The scope
Six pieces of work. The first one decides what the second locale costs for the next five years.
Content types modelled around what you actually publish, each carrying its own locale field so English and Arabic are one model rather than two sites
a content source a second surface can read without a migration
A versioned content API with a documented shape, so a new reader can be built against it without changing what the existing ones receive
a contract, rather than a query written into a page
Pages pre-rendered from the content and served from the edge, on the routing and the build standard this pillar already sets
the first consumer of the model, built first because it is the one earning money
The store placed against your data-protection position, and the pages served from a node near the reader whatever that position turns out to be
the residency question and the speed question answered separately
The app, the portal or the screen wired to the same content, published from the same entry by the same person
one place to publish, and no second copy to keep in step
Content moved with its structure intact rather than pasted in as pages, every address mapped, and the search footprint recorded before the cutover so it can be checked after it
a replatform your rankings do not pay for
Our stack
Four content stores and the contract between them and the site. Select one to see when it is the right answer, and when it is not.
Sanity keeps both language versions of a document inside the same dataset rather than in a separate space, so one query and one set of generated types cover the English site and the Arabic one.
We generate types from the schema, so a field added for the Arabic locale surfaces as a compile error on every surface that reads it rather than as an empty space on one of them nobody noticed.
How the build runs
A replatform rather than a first build, so it starts from what already exists. The sequence runs after the recommendation, and the recommendation is sometimes not to run it.
We list every place the content has to appear, now and in the year ahead, and model the content types against that list rather than against the current sitemap. The locale field goes on every type in the same fortnight, even where only English is funded. If the list comes back with one surface on it, that is what the recommendation says, and the scope becomes a better content model on a simpler stack.
The store is set up and populated, the API shape is fixed and documented, and the front end is built as its first reader. Existing content moves with its structure rather than as pasted pages, every address is mapped, and the search footprint is recorded before the cutover so it can be checked against afterwards rather than argued about.
The app, the portal or the Arabic locale arrives as another reader of the same API, published by the same person from the same entry. Nothing about the website changes to make room for it, which is the whole reason the architecture was worth its bill. What still needs a developer is written down rather than discovered.
The surfaces are counted before an architecture is recommended, and the count is handed over with the recommendation.
Our commitment
Headless is easy to sell and expensive to regret. These four are what we ask to be held to instead.
We say when the answer is no.
We count the surfaces before recommending an architecture, and where the honest answer is one website with a better content model, that is the answer you get. It is the smaller invoice and it is still the right one.
Leave with your content intact.
The store exports as structured data rather than as finished pages, and the model is documented, so a second front end can be built against it by somebody who is not us. Nothing is locked in a format only we can read.
The locale field goes in anyway.
Every content type carries its locale from the first commit, so adding Arabic later is content and layout work rather than a second migration. Where the translation is out of scope, we write that down instead of implying it.
Nothing modelled for a phantom surface.
The model covers the surfaces you named and no more. An over-modelled store is the commonest way a headless build becomes something the team stops publishing in, and adding a type later is far easier than removing one.
Common questions
Keep exploring
A design system drawn for both reading directions, not screens.
Builds sequenced around the approvals the launch date waits on.
Flows and states tested with real people before anything is built.
Stores wired for the payment set, the courier and the invoice.
The plan decides more than the theme. We settle that first.
A store you own outright, with the running cost priced first.
Built for the two people who have to publish it, in both scripts.
The origin, the scripts and the consent layer, not the network.
Diagnosis first, and a test only where the traffic carries one.
Next step
Tell us where your content has to appear and who publishes it. We will tell you whether headless is worth the cost, or whether a simpler build gets you there.
Tell us what you need.