MetalFlows needed a single system to handle quotes, orders, VAT-compliant invoicing, and profit tracking — in both English and Arabic. Building for a Saudi trading firm taught us that internationalisation is a product decision, not a feature.
MetalFlows is a metal trading company based in Saudi Arabia. Their sales team writes quotes in English for some clients and Arabic for others. Their accountant produces VAT-compliant invoices that have to meet ZATCA requirements. Their director wants a profit ledger that shows margin per deal without asking the accountant to run a report. All of this, historically, was split across spreadsheets, a separate invoicing tool, and a lot of WhatsApp messages.
Our job was to build one system that covered quote to delivery, in both languages, with the numbers always correct.
The first thing we learned: making a product work in Arabic is not about adding a translation file. Arabic is right-to-left. Numerical formats differ. Currency display conventions differ. The word order in a sentence can change the meaning when translated directly rather than naturally. And in a B2B context, the formality of language in a quote document carries commercial weight — a poorly worded Arabic quote signals that the seller does not know the market.
We hired a native Arabic speaker to review every string in the application, not just translate it. The translated strings from a direct translation tool were technically correct but commercially wrong — too casual, wrong register, missing the courtesies that a Saudi business contact would expect. This took two extra weeks and was completely worth it.
The RTL layout shift also required revisiting almost every component. Flexbox direction, icon placement, form field alignment, table column order — all of it inverts. We had to audit every screen twice, once per language direction.
ZATCA (Saudi Arabia's tax authority) has specific requirements for compliant invoices: QR codes encoding specific transaction data, mandatory fields in Arabic, precise date and time formats, sequential invoice numbering with no gaps. These requirements shaped the data model more than anything the client asked for.
We built the invoice generator around the compliance requirements first and worked backward to the user interface. It is easier to design a good UI on top of a correct data model than to retrofit compliance onto a UI-first design.
The director wanted to see margin per deal — revenue minus cost of goods, after delivery expenses. Sounds simple. In practice, costs arrive at different times: the purchase price is known at order, delivery costs sometimes arrive days later, and occasionally a client dispute results in a credit note that changes the effective revenue.
We modelled the profit ledger as a series of ledger entries, each dated, each attributed to a specific deal, each reversible. The display reconciles them at query time rather than storing a running total. This meant the numbers are always correct even when a cost arrives late or a credit note changes the picture weeks after delivery.
Do not treat localisation as the last step. The moment you know your product will serve a non-English market, make a localised screen part of every design review. Seeing the product in context — right layout, right language — catches problems that no amount of English-language review will surface.
And hire someone from that market for the review, not just the translation. The commercial and cultural context they bring is the difference between a product that works and a product that wins trust.
Drop us a message or call us directly. We reply to every enquiry — usually the same day.