Your design, built.
The approved design built in a framework, responsive from a phone held in a lift to a desk monitor
a front-end nobody has to re-theme
Website development · UAE
Webzenia builds in a framework you own, in a repository opened under your own entity. The gateway and the identity rail are applied for while the code is still being written.
Get a build plan for the siteWhat sets the date
Website development is the engineering behind a site that ranks, scales and reaches the systems the business already runs. Here those connections are approvals before they are integrations.
Built in a framework, in a repository you own, and readable by whoever picks it up next. The stack is chosen for what the site has to reach, and the reasoning is written down before anything is built.
The payment gateway, the identity provider, and the system an enquiry has to land in. Each one carries an approval, and that approval runs on someone else’s calendar rather than the sprint plan.
Repository, hosting, domain and analytics, opened under your entity on day one. Several of them can only be opened by the licence holder, so they were never ours to transfer at the end.
Two ways the same build is scheduled
Two quotes can name the same number of weeks and mean different things. The difference is whether the approvals started with the project or after the code was finished.
| Approvals at the endFiled once the code is done | Approvals from week oneFiled alongside the build | |
|---|---|---|
| The payment gateway | Applied for after checkout is coded, and the activity on the licence turns out not to cover it. | The merchant account is applied for while the catalogue is still being modelled. |
| UAE PASS | Planned as an API key, and the sign-in screen ships behind a form nobody can submit. | The onboarding application goes in at scoping, so sign-in is built against a real date. |
| The system it feeds | Requested in the final sprint, from a vendor whose support desk answers in working days. | Access to the CRM or the ERP is requested before the first component is written. |
| What moves the date | Whichever approval was filed last, and it is discovered rather than planned. | Rarely anything. The approvals were already running while the build was. |
| What the board hears | A date, then a revised date, then a third one. | A date, with the two things it depends on named beside it. |
Ask any supplier what they need from you in week one. If the answer is nothing, your licence has not been read yet. How a first build is scoped sits one level up, what your licence lets the site claim is the Dubai read, and connecting the systems behind it is where the integration work lives.
From the field · UAE builds
Webzenia has worked with Gulf clients since 2018. The same three things sit between a finished build and a live one, and none of them is code.
A payment gateway needs a trade licence and a merchant account under an activity that covers selling online, whether the provider is Network International, PayTabs, Telr or Checkout.com. UAE PASS is an onboarding application to a federal programme. A Business Bay brokerage on a DET mainland licence unblocks neither by writing code faster.
AWS has run an in-country region here since 29 August 2022, across three availability zones, and CloudFront already serves from Dubai. So delivery speed is an edge question. Residency is a compliance one, and for a DIFC-registered fund it changes the architecture rather than the hosting invoice.
A merchant account is issued against your trade licence, a UAE PASS integration to your entity, and a .co.ae asks for a licence before it registers. An agency holding those for a Musaffah contractor on an Abu Dhabi mainland licence holds a login, not the account. That login is the one that goes quiet.
The scope
Six deliverables, each with something you own at the end of it. The order they are started in is the part that decides the date.
The approved design built in a framework, responsive from a phone held in a lift to a desk monitor
a front-end nobody has to re-theme
Measured on real hardware over mobile data before launch, never on the machine that built it
numbers that survive the first month of content
Semantic markup, server-rendered HTML and structured data shipped with the build rather than retrofitted
pages a crawler reads on the first request
An editor two people can run, wired to the payment gateway, the identity rail and wherever an enquiry has to land
a site your team changes without us
Modules and routes that take new sections, a second script and more traffic without a fork in the codebase
an architecture the next feature fits into
Deployed to the region your compliance position requires, with repository, domain and analytics already under your entity
accounts you never have to reclaim
Our stack
Five tools, chosen for who has to maintain them after we leave. Select one to see what it buys, and when we would build the same thing differently.
Next.js keeps the page and the code that answers a payment webhook in one deployment, so an integration does not need a second service to be approved, hosted and maintained beside the site.
Every rail sits behind a route handler in the same repository, so a gateway still in onboarding runs against a stub and swaps to the live merchant account without touching anything else. Where a site is genuinely five static pages, we would say so and build it as five static pages.
How the build runs
The sprints are ours to control and the approvals are not. So both start in week one, and the schedule names which of them the launch date depends on.
We read the trade licence, list what the site has to reach, and file each request that runs on somebody else’s calendar: the merchant account under an activity that covers selling online, the UAE PASS onboarding, and access to the CRM or the ERP. Each comes back with a date, and those dates go on the plan beside the sprints rather than in a risk register nobody opens.
Components, content model and routes are built while the approvals run, with every rail behind an interface rather than wired into the pages. The consent layer is in place before the first analytics tag is allowed to fire, because the UAE PDPL treats consent as the primary lawful basis rather than something a banner may assume.
A rail goes live the day its approval lands, rather than on a single launch day that waits for the slowest one. The site can be live and taking orders on one gateway while a second is still in onboarding, and because every account was opened under your entity at the start, nothing has to be transferred afterwards.
We file them, we chase them, and the weekly note says what the date is waiting on and who it is waiting on.
Our commitment
A build is easy to quote and hard to hold to a date. The four terms below are fixed before anything is signed.
Fixed scope, fixed price.
The scope and the price are agreed before the first component is written. Where an approval comes back needing work nobody scoped, you get the cost in writing before we start it, not on the invoice after.
Every account under your entity.
Repository, hosting, domain, analytics and the merchant account are opened in your name, with Webzenia added as a user. Nothing is transferred at handover, because nothing was ever held on your behalf.
The stack decision, in writing.
You get the framework, the CMS and the hosting choice as a written recommendation, with what each costs to run and what it would take to reverse. The reasoning stays in the repository, so the next developer can read why as well as what.
One named lead throughout.
One person owns the build, files the approvals and answers for the date, and is still the contact at handover. Not a rotating queue, and not an account manager relaying answers from somewhere else.
Common questions
Keep exploring
A design system drawn for both reading directions, not screens.
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.
For content that has to reach more than one surface.
The origin, the scripts and the consent layer, not the network.
Diagnosis first, and a test only where the traffic carries one.
Next step
Send the current site or the brief. We will come back with the stack, the integrations, and which of them has to start in week one.
Tell us what you need.