Notes from the workshop.

The sentence sounds reasonable in a kick-off meeting. English first, get to market, add Arabic in phase two. It is reasonable — right up until someone tries to do it.

What actually changes in right-to-left

Translating text is the small part. When the direction of a layout flips, so does almost everything attached to it:

• Navigation, sidebars and page structure mirror horizontally — a logo that sat left now sits right.
• Icons with direction change meaning. A “next” arrow must point the other way; a “reply” icon must not.
• Form flow reverses: labels, validation markers, checkbox alignment, the order of a name field pair.
• Numbers, dates, currency and phone formats follow their own rules, and mixed Arabic-Latin strings break naively written line-wrapping.
• Arabic text runs roughly 20–25% shorter than English in some contexts and considerably longer in others, so fixed-height cards designed around English copy simply fail.
• Typography changes entirely. Arabic needs a different font stack, a different line height, and it does not support italics or capitalisation as emphasis.

Why the cost is not linear

Built in from the start, bilingual support is a structural decision. Layout uses logical properties rather than left and right; components are tested in both directions from the first week; copy is written into a translation file instead of typed into the markup. The extra effort is real but modest — commonly in the range of ten to twenty per cent of front-end work.

Retrofitted afterwards, it is a partial rebuild. Every hard-coded margin, every absolute position, every icon and every fixed-height container has to be found and reworked. The testing burden doubles because both directions must now be verified on every screen. In our experience the second pass regularly costs more than the original build of the same screens, because you are paying for archaeology as well as engineering.

What to ask a supplier

Three questions expose the difference quickly. Do your components use logical CSS properties, or left and right? Is Arabic copy handled through a translation file from day one, even if it is empty? Will you demonstrate the interface in Arabic during the build, not only at the end?

If Arabic is genuinely out of scope forever, say so and save the money. If there is any chance it is coming, the cheapest moment to prepare for it is before the first component is written.

Most disputes between a client and a software supplier are not about quality. They are about whether something was included. A scope document exists to make that argument impossible, which is why a vague one benefits whoever wrote it.

The six checks

• An explicit out-of-scope list. Any document can list what is included. A serious one names what is deliberately excluded — the second language, the mobile app, the migration of ten years of legacy data, the integration nobody has priced yet.
• Acceptance criteria per milestone. Not “design complete” but what specifically must exist for you to sign that milestone off. Without this, “done” is a matter of opinion, and the opinion that counts is usually the supplier’s.
• Named assumptions and dependencies. What the supplier is assuming about your content, your existing systems, your API access, your response times. Every unstated assumption is a future change request.
• A change procedure with a price mechanism. Scope will change; that is normal. What matters is that a change produces a written estimate before work starts, rather than an invoice afterwards.
• Ownership, stated plainly. Who owns the source code, the designs, the domain and the cloud accounts, and at what moment ownership transfers. “On final payment” is common and acceptable. Silence is not.
• What happens after launch. How long defects are fixed for free, what counts as a defect rather than a new feature, and what support costs from then on.

One warning sign

A proposal with a large number and a short description is not a simpler proposal — it is an unfinished one. If a supplier cannot describe the work in detail before starting, they have not yet thought about the work in detail, and the difference will appear in your timeline rather than in theirs.

Use these six on us as well. If our scope document fails any of them, that is a fair reason to push back before signing.

“The data must stay in the UAE” is a requirement that arrives late in a lot of projects, usually from a lawyer or a procurement form, and it can quietly change your architecture and your hosting bill.

What residency actually means

Data residency is about where information is physically stored and processed. Both major clouds now offer in-country options: AWS operates a Middle East region in the UAE (me-central-1) and Microsoft operates UAE North in Dubai. Choosing one of those regions is the straightforward part.

The harder part is everything around the database. Backups, log aggregation, analytics tools, email delivery, error monitoring, customer support software and AI services all move data somewhere, and their default location is frequently not the UAE. A system can be “hosted in Dubai” while quietly shipping its error logs to Ireland.

Three questions to ask

• Which regime applies to us? The UAE federal data protection law (Decree-Law 45 of 2021) applies broadly, while DIFC and ADGM operate their own separate regimes. Which one you fall under changes the answer.
• What has to stay, and what merely should? Personal data of customers is one question; anonymised analytics is another. Treating everything as maximally sensitive is the most expensive possible reading of the requirement.
• Who outside the country can access it, and is that written down? Residency is not only about storage. If an engineering team abroad can log into production, that access needs to be documented, limited and disclosed — which is a governance question, not a hosting one.

What it costs

In-country regions are typically somewhat more expensive than the largest global regions, and they occasionally lag on newer managed services, which can force a design change. Neither is a reason to avoid them — it is a reason to decide before building rather than after, because moving a live database between regions is a project of its own.

We are not lawyers. For a regulated product we work alongside your legal advisor and implement what they determine, rather than interpreting the law on your behalf.

A backend — your own server, database and API — is the single largest recurring cost in most custom products. It is also, for a first version, sometimes unnecessary. These five questions usually settle it in one conversation.

1. Does more than one person need to see the same data?

If every user only ever reads and writes their own information, a great deal can live on the device or in a managed service. The moment two people must see one shared, consistent state, you need somewhere central for that state to live.

2. Does anything need to happen when nobody is using the app?

Scheduled reports, reminders, overnight synchronisation, payment retries. Work that must occur without a person present needs a server somewhere. Interfaces alone cannot do it.

3. Is there a rule you cannot let a user break?

Pricing, discounts, credit limits, permissions. Anything enforced only in the app can be bypassed by someone technical enough to try. Rules that carry money or access have to be enforced on a server you control.

4. Do you hold data that would be damaging if leaked?

Personal records, identity documents, health or financial information. These require controlled access, audit trails and considered retention — the kind of thing that is difficult to do properly without a backend and a deliberate design.

5. Will you need to change behaviour without shipping an update?

Content, pricing tables, feature toggles. If those must change weekly, having them served from somewhere central saves an app-store review cycle every time.

If you answered no to all five

Your first version may be a well-built interface on top of managed services — authentication, a hosted database, a payment provider — with no custom server at all. It is faster, materially cheaper, and it can be extended later once real usage tells you what you actually need. A supplier who quotes a full backend without asking these questions is quoting a habit, not a design.

A project is not finished when the software works. It is finished when your company could continue without the people who built it. That is a different, and much less common, standard.

The checklist

• Source code in a repository owned by your organisation, not by an individual or the supplier.
• Cloud accounts registered to your company, with billing in your name and an owner-level administrator on your side.
• Domain registrar and DNS access, with the registrar lock and renewal dates confirmed.
• Every third-party service account — payments, email, maps, analytics, error tracking — listed with its owner and renewal cost.
• Environment variables and secrets transferred through a secure channel, then rotated so the old values no longer work.
• A written architecture note: what runs where, what talks to what, and which parts are known to be fragile.
• Deployment documented well enough that a competent engineer who has never seen the project can release a change.
• Database schema documentation and the migration history, so future changes are versioned rather than manual.
• A backup and restore that has actually been rehearsed, ideally with you watching.
• Monitoring and alerts pointing at addresses your team controls, not only the supplier’s inbox.
• Design source files, brand assets and font licences, in editable formats.
• App store and Play Console entries under your developer account, with signing keys transferred and backed up.
• A recorded walkthrough for the people who use the system daily, in plain language rather than technical terms.
• A written list of known limitations and the things we would do next, so nothing lives only in someone’s memory.

Run this against your current supplier before the next payment. If several items are missing, that is not necessarily bad faith — but it is a dependency, and dependencies get expensive precisely when you want to leave.