Software Development in Saudi Arabia: Vision 2030, Regulations and Market Opportunities
What international software businesses need to know about building in the KSA market — from Saudi payment gateways and PDPPL data protection to Vision 2030 opportunities, Arabic RTL requirements, and VAT compliance.
There are few places on earth where the gap between current reality and stated ambition is being closed as visibly as in the Kingdom of Saudi Arabia. In less than a decade the country has moved from a heavily oil-dependent economy with a nascent tech scene to one of the most active digital transformation markets in the world. New government services have moved online. Consumer fintech has exploded. Entertainment venues, streaming platforms, tourism infrastructure, and healthtech ecosystems that simply did not exist in 2016 now receive billions in investment and government support.
We have been working with Saudi clients at Cyberbeak since before this acceleration became a headline story, and the pace of change has been extraordinary to watch from the inside. The market is genuinely exciting — but it also punishes teams that treat it as an extension of a Western or even a UAE-based product. Saudi Arabia has its own regulators, its own payment infrastructure, its own data protection law, its own language and calendar requirements, and a cultural and commercial context that shapes every design and architecture decision.
This guide covers the things you actually need to know before you build for the KSA market: the regulatory landscape, the payment gateways, the VAT compliance requirements, the data residency rules, the Arabic-first design expectations, and the cultural considerations that determine whether a product lands or fails. We have written it the way we brief our own engineering and design teams — with enough specific detail to make real decisions, not just a surface-level overview.
Vision 2030 and the Technology Opportunity
Vision 2030 is the economic and social transformation programme announced by Crown Prince Mohammed bin Salman in 2016. Its core objective is to reduce Saudi Arabia's dependence on oil revenue by developing non-oil sectors — tourism, entertainment, manufacturing, finance, technology — and to create a knowledge-based economy with a highly skilled Saudi workforce.
For software companies, Vision 2030 translates directly into procurement budgets, regulatory incentives, and enormous greenfield demand across several verticals.
Digital Government
The Saudi government has committed to becoming one of the world's top digital governments. The Saudi Digital Government Authority (SDGA) oversees the transformation of public sector services, and the ambition goes beyond putting forms online. Projects like the National Single Sign-On (SSO) platform, the National Data Management Office (SDAIA) and the national Nafath digital identity system are building the infrastructure on which an entirely new layer of citizen-facing software will sit. Any company building government-adjacent software in Saudi Arabia will interact with these systems, and understanding them is essential.
Smart Cities and NEOM
NEOM — the $500 billion linear city project in Tabuk province — is the most visible of the Vision 2030 megaprojects. It is not just a construction project; it is an attempt to build an entirely new urban operating system. The software requirements for NEOM span IoT, mobility, energy management, healthcare, commerce, and citizen services, and they come with expectations around Arabic-first interfaces, Hijri calendar support, and KSA data residency that any vendor must meet.
Beyond NEOM, projects like Diriyah Gate, the Red Sea Project, and Qiddiya (the entertainment city) are each generating significant demand for hospitality software, booking systems, access management, and visitor experience platforms.
Fintech
The Saudi Central Bank (SAMA) has operated a fintech regulatory sandbox since 2018 and has issued dozens of fintech licences since then. Buy Now Pay Later providers, open banking integrations, digital wallets, and payment orchestration platforms have all grown rapidly. The number of digital payment transactions in the Kingdom nearly trebled between 2020 and 2023. Any consumer-facing product needs to take Saudi fintech seriously — not as an afterthought to add once the "real" work is done, but as a core design requirement.
Healthcare and Entertainment
Seha Virtual Hospital and the broader MoH digital health initiative represent one of the largest healthtech opportunities in the region. Entertainment was essentially zero as a commercial sector before 2016; it now encompasses live music venues, cinemas, streaming platforms, and a domestic gaming industry that the government is actively subsidising through the Saudi Esports Federation and related bodies.
Regulatory Landscape
Saudi Arabia's regulatory framework for technology is more layered than most markets, because different sectors are supervised by different authorities, and those authorities operate with different levels of maturity and predictability.
CITC — the Communications, Space and Technology Commission — is the primary regulator for telecom, internet services, and most technology businesses. If you are building a consumer platform that sits on top of internet infrastructure, CITC is the authority you will deal with for licensing and compliance questions.
SAMA (the Saudi Central Bank) regulates anything that touches money: payment processing, lending, digital wallets, open banking, insurance. If your product handles financial transactions, SAMA licensing requirements apply to you or to the payment providers you integrate with. Building a SAMA-licensed fintech product from scratch is a multi-year compliance exercise; most product teams integrate with licensed providers rather than seeking their own licences.
ZATCA (the Zakat, Tax and Customs Authority, previously known as GAZT) administers VAT and the national e-invoicing system. We cover ZATCA compliance in detail below, but every software product that generates invoices in Saudi Arabia — which means almost every B2B product and most B2C products — needs to be ZATCA-aware from day one.
MOH (the Ministry of Health) oversees healthtech, telemedicine licences, and data standards for medical software. The regulatory environment here is still evolving, but data localisation and Arabic language requirements are strictly applied.
NCA (the National Cybersecurity Authority) sets cybersecurity standards for critical sectors including finance, energy, telecommunications, and government. If your software serves any of these sectors, NCA's Essential Cybersecurity Controls (ECC) and Cloud Cybersecurity Controls (CCC) frameworks apply. These are not advisory — compliance is a hard requirement for procurement in regulated sectors.
Saudi Data Protection: PDPPL
The Personal Data Protection Law (PDPPL) is Saudi Arabia's primary data protection regulation, enacted in 2021 and enforced in phases from 2023 onwards. It is enforced by the National Data Management Office (NDMO), which sits under SDAIA.
What PDPPL Requires
PDPPL follows a broadly GDPR-shaped framework: lawful basis for processing, purpose limitation, data subject rights (access, correction, erasure), mandatory breach notification, and restrictions on cross-border data transfers. If your software collects, processes, or stores personal data about Saudi individuals, PDPPL applies to you — regardless of where your company is incorporated.
The key obligations for software products are:
- Lawful basis: You must have a clear legal basis for every category of personal data you process. Consent is one option, but contractual necessity and legitimate interest are also recognised.
- Data subject rights: Your product must support the ability for users to access their data, correct inaccurate information, and request deletion — with defined response timelines.
- Cross-border transfers: Transferring personal data outside the Kingdom requires either that the destination country has an adequate level of protection (as determined by NDMO) or that specific contractual safeguards are in place. This is one of the most practically significant requirements for any product that uses offshore infrastructure.
- Data processing agreements: If you use third-party processors (cloud providers, analytics tools, support platforms), you need formal agreements that meet PDPPL standards.
- Breach notification: Breaches affecting personal data must be reported to NDMO within defined timeframes.
How It Compares to GDPR
PDPPL is substantively similar to GDPR in its structure and intent, but there are meaningful differences. The consent requirements under PDPPL are in some respects stricter — particularly around sensitive categories of data, which include health, financial, and location data. The cross-border transfer rules are also more prescriptive, because the list of "adequate" countries is determined domestically by NDMO rather than being aligned with an existing international framework.
What Software Products Must Do
In practical terms, PDPPL compliance for software means: privacy-by-design architecture, a consent management system for Saudi users, data subject request workflows built into your admin tooling, and a clear data map that shows where personal data is stored and processed. If your product is already GDPR-compliant, the delta is manageable — but it is not zero. Saudi-specific consent flows and Arabic-language privacy notices are required, not optional.
Data Residency and Cloud Infrastructure
Data residency is one of the areas where Saudi Arabia diverges most sharply from global defaults. For consumer software targeting private individuals, residency requirements are less prescriptive — but for any product serving government entities, financial institutions, or the energy sector, there is a strong expectation (and in many cases a hard requirement) that data is stored within the Kingdom.
Saudi Aramco has its own internal cloud and data governance policies that require supplier data to remain within Aramco-controlled infrastructure. SDAIA has issued guidance requiring that government data be hosted in KSA. SAMA has issued cloud guidelines that effectively require financial data to be held onshore.
Cloud Options in KSA
The infrastructure landscape has improved significantly since 2022:
- AWS Riyadh Region (me-south-1 / me-central-1) — Launched in 2022 and now the most widely used option for enterprise and regulated workloads. Full suite of services available. Generally the starting point for teams already on AWS.
- Oracle Cloud Riyadh — Strong traction with government and enterprise clients, particularly where Oracle ERP is already deployed. Oracle's dedicated region model (hosted in customer data centres) is attractive for organisations with strict residency requirements.
- Microsoft Azure Saudi North — Available and widely used, particularly in organisations already using Microsoft 365 and Azure Active Directory. Azure Government Cloud features are relevant for public sector work.
- G42 Saudi — The Abu Dhabi-headquartered cloud and AI company has a significant presence in KSA and offers sovereign cloud solutions that are particularly well-positioned for government procurement.
For most projects, the architecture decision is straightforward: deploy on AWS Riyadh or Azure Saudi North for standard enterprise and consumer workloads, use Oracle or G42 when the client has specific sovereign cloud requirements or existing vendor relationships that make them the right fit.
The practical implication for software architecture is that you cannot assume your existing multi-region deployment covers Saudi Arabia. You need KSA-specific infrastructure, and you need it designed in from the start — retrofitting residency requirements onto a product built for a single global region is painful and expensive.
Payment Integration for Saudi Arabia
Saudi Arabia's payment ecosystem is distinctive, and getting it wrong is one of the fastest ways to lose users. The country has its own national card network, its own dominant mobile wallet, a set of local payment gateway providers, and a rapidly growing BNPL market — all of which run alongside Apple Pay and Google Pay adoption rates that are among the highest in the world.
The Landscape
| Gateway / Method | Type | Notes |
|---|---|---|
| Moyasar | Payment gateway | Developer-friendly REST API, excellent documentation, supports Mada + Visa + Mastercard + Apple Pay + STC Pay. Recommended starting point for most projects. |
| HyperPay | Payment gateway | Widely used for enterprise and government projects; strong regional presence across MENA. |
| STC Pay | Mobile wallet | 35 million+ users; the dominant Saudi digital wallet. Essential for any consumer-facing app. Available via direct API or through Moyasar/HyperPay. |
| Mada | National debit network | The Saudi national debit card scheme. Mandatory for any product that wants to serve the majority of Saudi consumers, who use Mada as their primary payment method. |
| Tamara | Buy Now Pay Later | The leading Saudi BNPL provider. SAMA-licensed. Significant uplift on conversion rates for e-commerce and retail. |
| Tabby | Buy Now Pay Later | Strong competitor to Tamara, particularly for fashion and lifestyle verticals. SAMA-licensed. |
| Apple Pay | Digital wallet | Extremely high adoption in Saudi Arabia. Should be treated as a first-class payment method, not an optional extra. |
| Google Pay | Digital wallet | Lower adoption than Apple Pay in KSA but growing, particularly on Android mid-range devices. |
Our Recommendation
For a new consumer app, we start with Moyasar as the gateway layer: it handles Mada natively, supports STC Pay and Apple Pay, and the integration quality is genuinely good. Then we add Tamara or Tabby (or both) if the product involves any kind of retail or instalment-friendly purchase flow. STC Pay is non-negotiable for anything targeting mass-market Saudi consumers — the user base is too large to ignore.
For B2B or enterprise products, HyperPay is often the right choice, particularly when the client already has a banking relationship that makes HyperPay's settlement process smoother.
One critical point: Mada is not just another card scheme. In Saudi Arabia, debit cards on the Mada network are the primary payment instrument for a large proportion of the population. If your checkout does not accept Mada, you are excluding the majority of Saudi card users. Any gateway you choose must support Mada explicitly — do not assume international card acceptance covers it.
VAT at 15%: ZATCA Compliance
Saudi Arabia introduced VAT at 5% in January 2018, then tripled it to 15% in July 2020. This is significantly higher than the UAE's 5% rate and is one of the first things that surprises businesses entering the market from the Gulf region.
E-Invoicing: Fatoorah
ZATCA has mandated a national e-invoicing system called Fatoorah (Ùاتورة — the Arabic word for invoice). The mandate was rolled out in two phases:
- Phase 1 (December 2021): All VAT-registered businesses must generate and store invoices in a structured digital format. Paper-only invoicing is no longer compliant.
- Phase 2 (rolling from January 2023): Invoices must be integrated with ZATCA's systems in near-real time. B2B invoices must be cryptographically stamped and submitted to ZATCA for clearance before being issued to the buyer. B2C invoices must be reported to ZATCA within 24 hours.
Phase 2 is being rolled out in waves based on annual revenue thresholds, with the largest businesses first. By 2025, it covers essentially all VAT-registered businesses.
What This Means for Software
If your product generates invoices — and most B2B SaaS products, e-commerce platforms, and enterprise systems do — you need to build ZATCA-compliant invoicing from the ground up. This means:
- Structured XML format (UBL 2.1 based, with KSA extensions) for all invoices
- QR code on invoices containing encoded invoice data verifiable by ZATCA
- Cryptographic signing of invoices with a ZATCA-issued certificate
- API integration with ZATCA's PINT KSA platform for Phase 2 clearance and reporting
- Arabic language fields on invoices alongside English equivalents
- 15% VAT calculation and line-item display — ZATCA is strict about how VAT is shown
The practical implication: if you are building any product that handles commercial transactions in Saudi Arabia, you need either a ZATCA-compliant invoicing module built in, or integration with a certified accounting package (Zoho Books, QuickBooks KSA, SAP, Oracle Financials) that handles the ZATCA layer. Bolting this on after launch is significantly more expensive than designing for it from the start.
Arabic Language and RTL: KSA-Specific Considerations
Arabic RTL support is often treated as a design checkbox — flip the layout, mirror the icons, done. In Saudi Arabia, that approach produces software that looks patronising to native speakers and fails in practice. Arabic localisation for a Saudi audience is a product discipline, not a CSS property.
Arabic-First, Not Arabic-Added
For government projects and most enterprise software in Saudi Arabia, Arabic is the primary language and English is the secondary. This is the inverse of how most international development teams work. Arabic-first means that the information architecture, the copy decisions, and the UX flows are designed in Arabic from the start — with English as the translation layer. If you design in English and translate to Arabic, the Arabic interface will always feel like a translation. Saudi government users will notice immediately.
Hijri Calendar
Saudi Arabia officially uses the Hijri calendar (Islamic calendar) for government, religious, and many commercial contexts — alongside the Gregorian calendar for international business. Date-pickers and date display fields in government software must support Hijri dates, and your backend must store dates in a way that converts correctly between the two systems. This is not a minor cosmetic requirement: displaying "2025" when a Saudi government user expects "1447" is a functional error, not a styling preference.
Arabic Numerals
Eastern Arabic numerals (٠١٢٣٤٥٦٧٨٩) are used in some formal Arabic contexts, though Western Arabic numerals (0-9) are widely understood and used in most digital interfaces. For government-facing software, confirm with your client which numeral set is expected — do not assume Western numerals are always acceptable.
Modern Standard Arabic vs. Dialect
Modern Standard Arabic (Fusha / MSA) is the correct register for all formal interfaces: government software, enterprise dashboards, legal documentation. Colloquial Saudi dialect (Najdi or Hejazi) is not appropriate for UI copy, even though it is how Saudi people communicate in everyday speech. This distinction matters for any copy that goes into the interface — work with a professional Arabic copywriter who understands formal UI language, not just a translator.
Font and Typography
Not all fonts that support Latin characters include a full Arabic glyph set. We use typefaces specifically designed for Arabic digital contexts — Noto Sans Arabic, Tajawal, Cairo, and IBM Plex Arabic are reliable choices that work well in both RTL and LTR mixed-language layouts. Test with long Arabic strings: Arabic text in many UI elements runs longer than the English equivalent and will break layouts that were not designed with sufficient flexibility.
Cultural and Business Considerations
Building software for the Saudi market is not just a technical exercise. The commercial and social context shapes how products are perceived, how deals are made, and what features determine whether an application gets adopted.
Relationship-Driven Sales
Saudi business culture is deeply relationship-oriented. Procurement decisions — particularly in the government and enterprise sectors — are influenced heavily by trust, personal relationships, and local presence. This does not mean products do not need to be good; it means that good products do not sell themselves the way they might in more transactional markets. Having a local partner, representative, or business development presence in Riyadh accelerates every stage of the sales cycle. Cold inbound digital-only sales motions are slower in KSA than in most other markets.
Ramadan
Ramadan significantly changes trading patterns. Consumer e-commerce and retail activity surges in the weeks before Ramadan and peaks during the holy month itself, then drops sharply immediately after Eid. Government procurement and B2B decision-making, by contrast, slows substantially during Ramadan as working hours are reduced and attention shifts. Plan product launches, feature releases, and sales campaigns around the Hijri calendar.
Gender Considerations in App Design
Some application categories — particularly in healthcare, fitness, and family services — have historically required gender-specific features or flows in Saudi Arabia. Women's health applications, gym management software, and family booking platforms sometimes need to maintain gender-separated data views or booking systems in line with client requirements and social expectations. This is less of a universal requirement than it was before 2016, but it remains relevant in specific verticals. We raise it with clients during discovery rather than assuming either direction.
Halal Flags in Food and Retail Software
If you are building a food delivery platform, restaurant management system, or retail catalogue, halal certification status is a standard product attribute in the Saudi context — equivalent to allergen labels in a European food platform. Your data model should include it; your UI should display it prominently.
Iqama and Workforce Products
The Iqama is the residency permit held by foreign nationals living and working in Saudi Arabia. If your product manages HR, workforce, or employee data for Saudi organisations, Iqama number is a required identity field — equivalent to the national ID number for Saudi nationals. Your identity and onboarding flows need to handle both.
How We Work With Saudi Clients at Cyberbeak
Our KSA client work spans government-adjacent enterprise platforms, consumer fintech applications, e-commerce systems, and internal tooling for organisations undergoing Vision 2030-aligned digital transformation. Working in this market has shaped how we approach every technical decision on a Saudi project.
Arabic-first design is our default for Saudi projects, not an optional localisation track. Our design process starts with Arabic wireframes when the primary audience is Saudi government or enterprise users. We work with professional Arabic copywriters who specialise in UI and UX copy rather than using translation as a finishing step.
Data residency architecture is defined during the initial technical design, not retrofitted later. For projects with regulatory requirements, we deploy on AWS Riyadh or Azure Saudi North and ensure that no personal or regulated data flows outside KSA without documented justification and the appropriate PDPPL safeguards.
ZATCA-compliant invoicing is something we have built into several client products. We implement the full Fatoorah Phase 2 pipeline — XML generation, QR encoding, cryptographic signing, ZATCA API integration — and we treat it as a core product requirement, not a compliance add-on.
Payment integration for our Saudi consumer products is built around Moyasar as the primary gateway, with Mada, STC Pay, Apple Pay, and BNPL (Tamara or Tabby) treated as first-class payment methods from the first sprint, not added during a second phase.
PDPPL compliance is part of our standard technical delivery for Saudi projects: consent management, data subject request workflows, breach notification procedures, and Arabic-language privacy documentation. We include a PDPPL gap assessment in our discovery process for any product that handles personal data.
We are not a Riyadh-based agency. We are a software development team that has built real products for the KSA market and understands the specific demands that market places on software architecture, design, and compliance. That distinction matters when you are making technical decisions that will take months to change.
Frequently Asked Questions
Do we need a Saudi entity to build software for Saudi clients?
You do not need a Saudi legal entity to build software for Saudi clients, but the calculus changes depending on the type of client and the contract value. For government and semi-government procurement, a local entity (or a joint venture with a Saudi partner) is often a practical requirement — not always a legal one, but a strong de facto expectation. For private sector enterprise and startup clients, a foreign entity is generally acceptable. For large regulated contracts, clients will ask about your local presence. We can advise on the right structure based on your specific situation.
Do you build Arabic-first applications?
Yes. Arabic-first design — where the primary UI is designed in Arabic and English is the secondary language — is our standard approach for Saudi government and enterprise projects. We work with specialist Arabic UX writers and test all interfaces with native Arabic speakers before delivery.
How do you handle PDPPL compliance in your projects?
Our discovery process includes a PDPPL data mapping exercise that identifies what personal data the product collects, where it is stored, what the lawful basis for processing is, and what data subject rights flows are required. We then build consent management, data subject request handling, and breach notification workflows as part of the standard product build — not as a separate compliance workstream. For products requiring data residency in KSA, we configure infrastructure accordingly during the initial architecture design.
What payment gateway do you recommend for a new Saudi consumer app?
Moyasar is our recommended starting point. It offers the best developer experience in the KSA market, supports Mada natively, integrates with STC Pay, and handles Apple Pay well. For BNPL, add Tamara and/or Tabby depending on your product category. If you are building in an enterprise or government context, HyperPay may be a better fit.
Can you integrate with Mada?
Yes. Mada integration is standard on all our Saudi consumer and e-commerce projects. We handle it through Moyasar or HyperPay depending on the client's gateway preference, and we test Mada flows explicitly — not just as a fallback card option but as the primary payment path, because it is how the majority of Saudi card users pay.
The Saudi market rewards teams that come prepared. The opportunity created by Vision 2030 is real and large, but it belongs to products that understand Arabic-first design, navigate the regulatory stack confidently, and treat local payment infrastructure as a core requirement rather than a regional edge case.
If you are building for Saudi Arabia and want a development team that has done it before, we would be glad to talk through your project. The first conversation is always a discovery call — no pitch deck, just a direct discussion of what you are building and what it will take to build it well in the KSA market.
Sprechen Sie mit unserem Team über Ihr Projekt
Wir arbeiten mit Unternehmen in Großbritannien, den USA, den VAE, Saudi-Arabien, Kanada, Australien und Deutschland zusammen, um maßgeschneiderte Software, SaaS-Plattformen und Marketplace-Systeme zu entwickeln.