Most financial products in the Gulf support Arabic. Fewer are built Arabic-first, and the difference shows exactly where it matters - on a statement, an invoice, or a contract a customer signs.
Numbers and currency
Arabic text runs right to left, but numbers within it run left to right, and a currency amount has to sit correctly in that mixed flow. Get the bidirectional handling wrong and 1,250.00 SAR renders as SAR 00.052,1 in the wrong place on the line. On a marketing page nobody notices. On a payment confirmation, it is a support ticket and a trust problem.
Dates and the calendar
Statements, due dates and reporting periods may need the Hijri calendar alongside the Gregorian one. That is a data and formatting decision that reaches the database, not a display toggle bolted on at the end.
Documents, not just screens
The PDF a customer downloads - the statement, the invoice, the signed agreement - is where RTL support most often fails, because the document renderer is a separate code path from the UI. An Arabic-first build treats the generated document as a first-class surface, tested in both languages.
Why it is cheaper to do first
Retrofitting Arabic means re-opening layout, data formatting and document generation after they are already built. Designing for both directions from the first commit costs a little more attention early and far less rework later. That is the whole reason we build this way.