Buying and running software in Saudi Arabia
Two requirements shape most Saudi projects, and both are structural rather than cosmetic.
The first is e-invoicing. ZATCA's Fatoora programme moved past simple PDF invoices into a phase requiring invoices to be generated in a defined format, carrying cryptographic elements and a QR code, and integrated with ZATCA systems. For any product that issues an invoice this is not a reporting feature added at the end — it constrains how invoices are numbered, stored and transmitted, so it is scoped at the start. The specific obligations depend on the business's turnover and wave assignment, which the operator confirms.
The second is Arabic. Arabic is expected as a primary language rather than a translation layer, which means right-to-left layout throughout, Arabic numerals and date handling where required, and content that reads as written rather than converted.
Payments centre on mada, the local debit scheme, which most domestic cards run on. A checkout handling only international card brands will decline a large share of real customers, so mada support through Tap, HyperPay or Moyasar is treated as a baseline rather than an addition.
Data residency comes up frequently. Where in-Kingdom hosting is required, that means infrastructure physically located in Saudi Arabia including backups and third-party services — a question reviewed explicitly, since regional proximity does not establish it.
Custom Software Development in Saudi Arabia
Saudi custom work usually starts with two non-negotiables: Arabic-first interface with right-to-left layout, and invoice handling that fits the ZATCA e-invoicing requirements applying to that business. Both affect the data model, so they are settled during scoping rather than added later. Hosting location, backups and third-party data flows are reviewed where in-Kingdom residency is required.