A licence and an office get you registered. They do not get you transacting. Saudi Arabia has its own e-invoicing regime, its own dominant payment rail, its own data residency expectations and a market that reads right to left. We are the Riyadh-based team that builds that layer — so your product works here the way it works at home.
In practice, five things. First, an Arabic interface — not a translation layer, but a right-to-left product that reads natively, because Arabic is the working language of most of the market and is expected in government-facing and consumer-facing contexts. Second, ZATCA-compliant electronic invoicing, which is mandatory for VAT-registered businesses and requires invoices to be generated in a specific structured format and cleared through the tax authority's platform. Third, support for mada, the Saudi domestic debit network, which carries a large share of card transactions in the Kingdom and is not covered by default international gateway setups. Fourth, a hosting and data position that satisfies residency expectations for regulated sectors. Fifth, integration with national digital identity where your service requires verified users. Most international products arrive with none of these and discover them after launch.
This is the checklist international companies usually receive only after they have already launched and something has failed. Each item below is a real engineering task, not a policy note.
A mirrored English layout is visibly wrong to an Arabic reader — broken letter joining, numerals in the wrong system, forms that flow against the eye. We rebuild the interface so Arabic is the design language and English is the parallel, which is the reverse of how most products are localised. This includes typography, number formatting, date handling, form order and the tone of system messages.
Saudi Arabia requires electronic invoices in a defined structured format, with clearance or reporting through the Zakat, Tax and Customs Authority platform depending on the invoice type. This is not a PDF with a logo. It is a schema, a cryptographic stamp, a QR requirement and an integration against a government endpoint. We build it into your billing flow rather than bolting a separate tool alongside it.
mada is the Saudi domestic debit network and carries a substantial share of card payments in the Kingdom. An international Stripe-only setup will decline a meaningful portion of genuine customers. We configure the local gateway stack — mada, HyperPay, Moyasar, PayTabs and Apple Pay — alongside whatever international processor you already use, so both work.
Financial services, healthcare and government-adjacent work carry expectations about where data physically sits. We deploy to in-region infrastructure — AWS Middle East, Google Cloud Dammam, or in-Kingdom providers where a stricter position is required — and document the architecture so your compliance team has something to review.
Where your product needs a verified Saudi identity — onboarding, contracts, regulated services — integration with the national identity and authentication platforms replaces the document-upload flow you would use elsewhere. It is faster for the user and it is what the market expects.
Not a criticism of them. It is simply knowledge that does not exist outside the market, and it is not documented well enough in English to be learned remotely.
Much of what governs digital operation here — tax authority technical specifications, platform integration documentation, sector guidance — is published in Arabic first and updated there first. A team reading translated secondary sources is always working from a stale version.
A Saudi user knows within one screen whether Arabic was designed or translated. Weak Arabic reads as a company that does not take the market seriously, and that impression does not recover. This is a craft problem, not a vocabulary problem.
Payment gateways, identity platforms and government endpoints have onboarding processes that assume a local entity, local documentation and, frequently, Arabic correspondence. Working through it from outside the country adds months.
Darb has run from Riyadh since 2012 and built its own multi-tenant SaaS platform on this stack — ZATCA-classified accounting, mada-capable billing, Arabic-first interface, in-region hosting. We are not learning this on your project.
No open-ended retainer. Each phase has a fixed scope, a fixed fee and something you can use when it ends. You can stop after any phase.
We review your product, billing flow, data architecture and go-to-market plan against what the Saudi market actually requires, and return a document your board can act on — what must change, what it costs, in what order, and what can wait.
Interface rebuilt so Arabic is native rather than mirrored. Typography, numerals, date handling, form flow and system message tone. English ships in parallel from the same codebase.
ZATCA e-invoicing built into your billing flow, local payment gateways configured alongside your existing processor, and VAT logic implemented against the local rate and classification rules.
In-region deployment, bilingual marketing presence, and an operational partner on the ground once you are live — so an issue at 10am Riyadh time is handled at 10am Riyadh time.
Arabic is the official language and is expected in government-facing contexts, consumer contracts and much commercial documentation. Beyond any formal requirement, it is a commercial necessity: the working language of the market is Arabic, and a product that only speaks English narrows its own addressable audience. Our recommendation is always to treat Arabic as the primary interface rather than a secondary toggle.
ZATCA is the Zakat, Tax and Customs Authority. Saudi Arabia mandates electronic invoicing for VAT-registered businesses, requiring invoices in a defined structured format with cryptographic stamping, a QR code and — for certain invoice types — clearance through the authority's platform before the invoice is valid. If you are VAT-registered in the Kingdom and issue invoices, it applies to you. It is an integration task, not a document-template task.
You can, but you will decline a meaningful share of genuine customers. mada is the Saudi domestic debit network and carries a large portion of card transactions in the Kingdom; an international-only gateway setup does not reach those cards. The practical answer is to run both — keep your existing international processor and add a local gateway alongside it, which is a standard configuration.
Not to begin. Readiness assessment and localisation work can run while the commercial entity is being established, which is usually the efficient order — the technical work takes as long as the licensing and can proceed in parallel. Some integrations, particularly payment gateway and government platform onboarding, do require the entity to be in place, so we sequence those to land after it exists.
For most commercial activity, in-region hosting such as AWS Middle East in Bahrain is sufficient and is what we would recommend for latency reasons regardless. For regulated sectors — financial services, healthcare, government-adjacent work — expectations are stricter and in-Kingdom hosting is the safer position. We assess which applies to your sector during the readiness phase rather than guessing.
Two weeks for readiness assessment, four to eight weeks for Arabic-first localisation, and four to ten weeks for compliance and payments — with phases two and three able to run partly in parallel. A realistic end-to-end figure for a company with an existing product is three to five months to being genuinely operational, not counting licensing, which runs on its own track.
Yes, and that is the common case. We run engagements in English, deliver remotely, and act as the local technical presence during the period when you do not yet have one. Several of the integrations genuinely need someone in the market, which is the practical reason this work is difficult to do from outside.
The readiness assessment is fixed-fee and scoped in the first conversation. Subsequent phases are quoted against the findings, because the cost of localisation and compliance work depends entirely on how your existing product is architected. We quote each phase separately and you can stop after any of them — there is no long-term retainer requirement.
The core engagement is Saudi-focused because it is the largest market and has the most specific technical requirements. Most of the work — Arabic-first interface, regional hosting, local payment rails — carries directly into the UAE and the rest of the Gulf. We run a Dubai operation as well, so a two-market entry is a single engagement rather than two.
Look at what we built for ourselves rather than at claims about ourselves. Darb built and runs Rouad, a multi-tenant SaaS platform covering lead generation, pipeline, quotes, contracts, accounting with local VAT classification, WhatsApp Business integration and HR — Arabic-first, bilingual, self-hosted, in production and running our own operation daily. The case study is on this site. It is the same team and the same stack.
A short description of your product and your target sector is enough. We come back with the specific list of what would need to change for the Saudi market, an order to do it in, and whether the readiness assessment is worth your time. That first answer costs nothing.