Bilingual GCC platform · Representative architecture

Arabic / English GCC Platform

Arabic support is not a translation file. It is a second reading direction running through every layout, every journey and every generated document.

The client is not identified and no metrics are published. What follows is the architecture and the reasoning behind it.

The problem

What was actually happening

A UAE marketplace required separate customer, service-provider and administration experiences with payments and bilingual usability. Three audiences with genuinely different jobs, two languages with opposite reading directions, and an operations team that has to be able to intervene in any of it — all on one platform, without three codebases.

The environment it landed in

  • Three distinct audiences on one platform
  • English and Arabic
  • Left-to-right beside right-to-left
  • Payments
  • Provider onboarding and supply
  • An operations team that needs to intervene
Before

How the work moved before.

Every step below was real work done by a person, and every handoff was a place the process could stop without anyone noticing.

What Octacer built

The system that replaced it.

  • 01

    Three role surfaces, one platform

    Customer, provider and administration are distinct zones with their own navigation and their own journeys, sharing one identity model and one data layer.

  • 02

    Direction as a property of the interface

    Layout, iconography, form flow and typography respond to reading direction, so Arabic is a first-class mode rather than a mirrored afterthought.

  • 03

    Payments in the journey

    Payment is part of the booking path on the customer side and part of the settlement view on the provider side.

  • 04

    API integrations

    External services are reached through defined interfaces, so the platform’s own surfaces stay thin.

  • 05

    Operational tooling for the admin side

    The operations team can find, inspect and intervene in any record — the part most marketplaces discover they need after launch.

Architecture

The decisions that make it hold.

Not a component list. These are the choices that determine whether the system is still trustworthy a year after launch.

Zone-based structure
Customer, provider and administration are separate zones over a shared core, which keeps three very different navigation models from contaminating each other.
Bilingual by construction
Language and direction are resolved once and applied throughout, rather than being patched into individual screens.
Role-based journeys
What a person can do follows from their role, and the journey is designed for that role rather than hidden behind permission checks on a generic screen.
Payments and settlement
Money moves through defined states on both sides of the marketplace.
Operational surfaces
Administration is a designed product surface, not a database client with a login.
Business effect

What changes once it exists

  • An Arabic-first user gets the same product, not a translated copy of someone else’s.
  • Providers and customers each get a journey designed for their job rather than a shared compromise.
  • Operations can intervene in a record without an engineer.
  • A GCC market can be served without forking the platform.

Why it matters — relevant for

  • GCC applications
  • Arabic portals
  • Marketplaces
  • Customer / vendor platforms
  • Bilingual systems
Full portfolio entry
Next step

Have a similar operational constraint?

Bring the process that looks closest to this one. We map it end to end before proposing anything.