UAE software delivery: settle Arabic, identity and hosting before the build

OutsourcingVN is operated by Netbase JSC, so this guide is written by a supplier with an interest in your decision. It draws on two bilingual Arabic and English platforms Netbase has built for Gulf clients, and on official UAE references for the questions your own advisers must answer. The guides index lists the other market guides.

Contents

• What makes a UAE-facing build different?
• What did Arabic acceptance involve in delivered bilingual work?
• How do you write Arabic and English acceptance?
• Should UAE PASS be in the first release?
• Worked scenario: a declined UAE PASS sign-in
• Where will the system and its data run?
• Which questions should you ask a supplier?
• What usually goes wrong?
• How this guide is sourced and where it stops
• Common questions
• Plan the first release

What makes a UAE-facing build different?

Three decisions shape a UAE-facing scope more than any feature list, and each needs an owner on the buyer's side.

• Language. Arabic is rarely a translation layer added at the end. It changes layout direction, fonts, search, names, numerals, generated documents and every message the product sends.
• Identity. UAE PASS is the national digital identity. The UAE PASS developer documentation describes an OAuth 2.0 integration with different account levels, which means the buyer has to decide which action needs which level of verified identity, and what happens for people who cannot or will not use it.
• Hosting. Some buyers want a public cloud; others need servers they operate themselves. The choice affects environments, monitoring, patching and the handover, so it belongs in discovery rather than in the last sprint.

The official UAE government page on data protection laws is the starting point for your legal advisers on which rules apply to your organisation, its free-zone or onshore structure, and the data in scope. Their conclusion becomes an engineering input: a data map, an access model and a hosting decision record.

What did Arabic acceptance involve in delivered bilingual work?

Two Netbase records show where Arabic support actually reaches in a working product.

• A reward shop platform for a Dubai-based loyalty and rewards technology company. Netbase delivered a headless multi-store platform on Magento 2 Open Source with a Next.js front end: individually branded reward shops per client programme, a hybrid points-plus-cash checkout, Arabic and English, single sign-on, payment gateways, and AWS or on-premise deployment, in four phases over 3.5 to 4.5 months. The loyalty reward shop platform record describes the scope; the client is not named.
• A web-to-print platform for Deyar Printing & Advertising in Riyadh. Netbase scoped and built a bilingual Arabic right-to-left and English platform with an online designer studio that handles Arabic fonts, templates and uploads, plus print-ready PDF generation with pre-flight checks and proof approval. The AI design and pre-press suite, ERP integration and ZATCA e-invoicing were planned third-phase work and are not presented as delivered. See the bilingual web-to-print platform record.

The practical lesson from both is that Arabic acceptance covers more than screens. It reaches each branded storefront, the design canvas, generated PDF files and the notifications a customer receives. The identity advice below draws on the official UAE PASS developer documentation.

How do you write Arabic and English acceptance?

Use a matrix like this one, and have a buyer-appointed language owner approve each row with real content rather than placeholder strings.

Test long strings, error states and empty states: a layout that works with a two-word label often breaks with a real Arabic sentence.

Worked scenario: a declined UAE PASS sign-in

A loyalty programme launches a bilingual member portal. A customer switches to Arabic, taps "Sign in with UAE PASS" and declines the consent screen.

Walking one scenario through staging exposes what a proposal must cover: the matching rule, Arabic messages, locked actions and the support view.

Where will the system and its data run?

The reward shop platform was built for AWS or on-premise deployment, which is a useful reminder that hosting is a design input. Decide early which environment hosts production and backups, who operates the servers, who applies security patches, and who receives monitoring alerts. If your advisers conclude that certain data must stay in a particular location, record that as a requirement with a named owner, and check that staging, logs and support tools follow the same rule. Our guide to data security and compliance in outsourcing lists the contract questions that sit around this choice.

Which questions should you ask a supplier?

• Which Arabic work have you delivered, and can we see it? A good answer names records and the parts of the product that were bilingual.
• Who approves Arabic content? A good answer puts that approval with your language owner and describes how changes reach production.
• How do you test right-to-left layouts? Look for real content, named devices and browsers, and a defect log.
• What happens when UAE PASS is declined or down? Look for a designed fallback and locked actions, not "we will handle it".
• Who holds the UAE PASS configuration? It should be your organisation, with the supplier working inside access you grant.
• Where do production data, backups and logs live? Expect one written answer covering all three.
• What is excluded? A good proposal lists planned later phases as exclusions rather than hiding them in the scope.

What usually goes wrong?

• Arabic added after the English build. Signal: layout defects multiply in the last sprint. Owner: the product owner, who should require bilingual acceptance from the first increment.
• Identity treated as a launch dependency without access. Signal: the release date waits on onboarding nobody has started. Owner: the business sponsor.
• Duplicate accounts after a later UAE PASS link. Signal: two profiles for one customer. Owner: engineering, with a tested matching rule.
• Unshaped Arabic in generated PDFs. Signal: disconnected letters in vouchers or receipts. Owner: operations, who must review real outputs.

How this guide is sourced and where it stops

This guide uses the UAE government data-protection page and the UAE PASS developer overview, both accessed on 2026-09-27, and two Netbase delivery records approved in the OutsourcingVN claim register. It is written for product, operations and procurement leads preparing a brief. It does not decide which laws apply to your organisation; that stays with your advisers. Netbase JSC's head office is in Hanoi, Vietnam, and it is the company's only office, so UAE work is delivered remotely, and Netbase delivery communication is in English.

Plan the first release

Bring the journeys you want in both languages, your UAE PASS decision, your hosting preference and the names of your language, business and security owners. The total software delivery cost worksheet helps you compare proposals that include Arabic review and identity testing, and the methodology explains how the claims on this page are recorded. For other markets, the Singapore guide deals with phased redevelopment and Myinfo data, the Nigeria guide with payments and messaging fallbacks, and the Cyprus guide with a different bilingual pattern around Greek and English in a small EU market. The Qatar guide covers a different Gulf pattern: the Personal Data Privacy Protection Law's cross-border provision, QCB-licensed payments and national identity sign-in.

Custom Product Engineering is the service for a bounded build, and global delivery explains how remote delivery is organised. OutsourcingVN is Netbase's own outsourcing-services platform: submit a project and a person will reply with whether discovery or a bounded implementation is the right next step.

Related services and solutions

Sources

• UAE Government, Data protection laws
• UAE PASS, Developer documentation overview