Skip to content

Stratgik — technology strategy and business systems engineering.
Delivery across the USA, UK, UAE and India.

Talk about a problem

Custom Software Development Cost in Saudi Arabia (2026)

Published 20 September 2026 · 10 min read

What a custom software build really costs in Saudi Arabia: PDPL data residency, ZATCA Phase 2 e-invoicing, Arabic localisation, tax and Saudisation.

Custom Software Development Cost in Saudi Arabia (2026)

The short answer

Custom software built for the Saudi market typically costs more than an equivalent build for a single Western market, and the gap is rarely about developer rates. It comes from four Kingdom-specific requirements that are easy to miss at budgeting time: hosting personal data in line with the Personal Data Protection Law (PDPL) and its cross-border rules, integrating with ZATCA's Fatoora e-invoicing platform if the system issues invoices, full Arabic and right-to-left localisation, and the tax and employment structure you use to deliver the work.

All four are predictable. Scope them at the start and they become line items; discover them in month four and they become a re-architecture. This article explains each driver, gives indicative planning ranges, and ends with a checklist you can take into a vendor conversation. Stratgik is a technology firm, not a law firm or tax advisor — confirm your specific obligations with qualified Saudi counsel.

Why a Saudi build is priced differently

A common failure pattern looks like this. A company commissions a platform from a vendor who has built something similar for Europe or South Asia. The demo is excellent. Then the Saudi entity's compliance team asks where customer records are stored, finance asks how invoices reach ZATCA, and the sales team asks why the Arabic interface reads awkwardly. Each answer requires reopening decisions made in week two.

None of this is exotic. Saudi Arabia has put in place a specific and enforceable set of rules about data, invoicing and workforce composition, and software that touches customers, payments or employees in the Kingdom has to sit inside them. That is an architecture question long before it is a compliance question, which is why it belongs in the cost conversation from day one.

Driver 1: data residency and the PDPL

Saudi Arabia's PDPL is actively enforced by the Saudi Data and Artificial Intelligence Authority (SDAIA). The accompanying Regulation on Personal Data Transfer outside the Kingdom came into force on 1 September 2024 and sets out the permitted routes for moving personal data abroad: an adequacy decision for the destination country, standard contractual clauses, or binding common rules for intra-group transfers. Continuous or large-scale transfers of sensitive data additionally require a documented risk assessment. Penalties under the regime reach SAR 5 million for administrative violations, with the possibility of doubling on repeat offences, and criminal exposure for certain unauthorised disclosures.

For a software budget, the practical consequence is where your database lives. Many organisations conclude that in-Kingdom hosting is the lower-friction path, particularly in regulated sectors or when selling to government — and the hyperscaler map is still filling in. Oracle has run a Jeddah region since 2020 and has added Riyadh. Google Cloud's Dammam region (me-central2) is live but restricted: Saudi-based customers buy through the exclusive reseller CNTXT, and customers outside the Kingdom need invoiced billing. AWS says its first Saudi region is on track for December 2026, backed by a stated $5.3 billion investment, so anything shipping before then means Bahrain or a non-AWS option.

The cost impact is rarely the raw compute price. It is the engineering work to make residency a design property rather than a configuration setting: separating data that must stay in-Kingdom from data that need not, building region-aware storage and backup, and producing the transfer records a regulator or enterprise procurement team will ask to see. Budget that as a discrete workstream, not a checkbox.

Driver 2: ZATCA e-invoicing integration

If your system issues tax invoices, it eventually has to talk to ZATCA. Phase 1 (generation) has applied to all resident taxpayers since 4 December 2021. Phase 2 (integration) began on 1 January 2023 and is being rolled out in waves by turnover, with each wave notified at least six months ahead. The thresholds have fallen steadily: wave 23 covers taxpayers whose taxable turnover exceeded SAR 750,000 in 2022, 2023 or 2024, with an integration window running from 1 January to 31 March 2026. Wave 24 follows with a 30 June 2026 deadline, and ZATCA has announced wave 25 at a threshold of SAR 187,500 with an integration date of 1 February 2027.

The direction is unambiguous: the net is widening to cover small businesses. Any invoicing, billing, POS, booking or subscription product commissioned in 2026 should have Phase 2 integration in scope from the start — cryptographic stamping, UUID and hash chaining, QR codes, clearance or reporting flows depending on invoice type, and Arabic invoice content. Retrofitting this is consistently more expensive, because it touches the invoice data model rather than just the output template.

Driver 3: Arabic and right-to-left done properly

Arabic support is often budgeted as a translation line item. It is an engineering line item. Right-to-left layout mirroring affects navigation, forms, tables, charts, icons with directional meaning, and every third-party component you did not write. Arabic numerals, Hijri and Gregorian dates, name and address formats and text expansion all have downstream effects on schemas and UI. Search and sorting behave differently, and printed output frequently needs separate work.

Teams that treat bilingual support as a first-class requirement from sprint one spend meaningfully less than teams that add it after the English version is signed off, because the second group ends up rewriting layout code and, occasionally, data models.

Driver 4: how the work is structured, taxed and staffed

Three structural points affect the number on the invoice.

VAT in Saudi Arabia has been 15% since 1 July 2020. Withholding tax applies to payments made to non-resident service providers, with domestic rates varying between 5%, 15% and 20% depending on the nature of the service; software payments characterised as royalties attract 15%, though applicable double-tax treaties can reduce this. If you are engaging an offshore development partner, WHT is a real cost that belongs in the model rather than a surprise at payment time — and it is exactly the sort of question to put to your tax advisor before signing.

Saudisation (Nitaqat) shapes the cost of any in-Kingdom team. The 2026 updates raised localisation quotas across several professional categories — 60% for sales roles from 19 April 2026, which explicitly includes IT and telecom sales specialists, and 30% for engineering professions from 30 June 2026 at establishments with five or more engineers. Quotas and scope change regularly, so verify your specific classification with the Ministry of Human Resources and Social Development or an employment adviser before you model headcount.

Indicative planning ranges

The table below is a planning aid, not a quote. These are the ranges we use internally when helping a client build a first budget; actual pricing depends entirely on scope, integration count and the delivery model you choose.

ScopeWhat it usually meansIndicative range (USD)Typical timeline
Internal tool or workflow appOne user group, few integrations, bilingual UI$25,000 – $60,0008 – 14 weeks
Customer-facing MVPWeb plus mobile, auth, payments, in-Kingdom hosting$60,000 – $150,0004 – 7 months
Platform with ZATCA integrationInvoicing or POS, Fatoora Phase 2, Arabic invoices$120,000 – $300,0006 – 12 months
Enterprise system or modernisationERP/CRM integration, migration, regulated sector controls$300,000+12 months+

Two adjustments on top. Annual maintenance, security patching and regulatory upkeep typically run at 15% to 25% of the original build cost each year, and in Saudi Arabia that upkeep is not optional, because ZATCA wave requirements and SDAIA guidance continue to evolve. And if the product handles personal data at scale or serves a regulated sector, add a compliance and security workstream rather than assuming the development team absorbs it.

Where budgets actually go wrong

AssumptionWhat tends to happen
"We'll add Arabic later"Layout and sometimes schema rework; the most common avoidable overrun
"Our existing cloud setup is fine"Residency review forces a migration mid-build, or a stalled enterprise deal
"ZATCA is a finance problem"Invoice data model cannot carry the required fields; rework in the core
"The offshore rate is the cost"WHT, VAT and coordination overhead were never modelled
"We'll hire locally once we launch"Saudisation ratios make the planned team shape unworkable

A checklist before you approve a budget

Work through these before signing a statement of work. Each one that is unanswered is a range, not a number.

  • Which categories of personal data will the system hold, and which of them must stay in the Kingdom?
  • If any data leaves Saudi Arabia, which transfer mechanism applies, and who is producing the risk assessment and transfer records?
  • Which cloud region are you actually deploying to, and is it available to you today — not on a roadmap?
  • Does the system issue tax invoices? If so, which ZATCA wave is your entity in, and is Phase 2 integration in the build scope or a later phase?
  • Is Arabic in scope from sprint one, including RTL layout, dates, sorting, search and printed output?
  • Who is the invoicing entity, and has withholding tax been modelled on cross-border payments?
  • What is the Saudisation position for any in-Kingdom roles the operating model assumes?
  • What does year-one maintenance cost, and does it include regulatory change?
  • Who owns the source code, the cloud accounts and the ZATCA credentials at the end of the engagement?
  • What is the smallest version that proves the business case, and can it ship in under 90 days?

Build, buy or configure

Not every Saudi requirement justifies custom software. If your invoicing is standard, a ZATCA-certified product will handle Phase 2 more cheaply than a bespoke implementation, and an established ERP with a Saudi localisation pack will usually beat a custom build for core finance. Custom development earns its cost where the process is genuinely yours, where no local product exists, or where integration between systems is the actual product.

Most successful Saudi technology programmes are hybrid: configured products for commodity processes, custom software for the parts that differentiate, and deliberate integration between them. Our build vs buy tool walks through that decision, and the app cost estimator gives a starting range you can pressure-test with vendors. If the decision is contested internally, a structured technology decision sprint is usually cheaper than three months of debate.

Frequently asked questions

Does Saudi law require all software data to be hosted inside the Kingdom?

Not as a blanket rule for all data. The PDPL framework restricts transfers of personal data outside Saudi Arabia and permits them through defined mechanisms such as adequacy, standard contractual clauses or binding common rules, with risk assessments required for continuous or large-scale sensitive-data transfers. Sector rules and government procurement requirements can impose stricter localisation on top. Confirm your specific position with Saudi legal counsel.

Can I use AWS for a Saudi project right now?

Yes, but not from an in-Kingdom AWS region. AWS has stated its first Saudi region is on track for December 2026. Until then, AWS customers needing regional proximity typically use Bahrain, while organisations that require in-Kingdom residency today look at Oracle's Jeddah and Riyadh regions, Google Cloud's Dammam region through CNTXT, or local and sovereign providers.

My company is small. Does ZATCA Phase 2 apply to me?

Increasingly, yes. Thresholds have fallen wave by wave — wave 23 reached SAR 750,000 of taxable turnover with an integration window in the first quarter of 2026, and wave 25 has been announced at SAR 187,500 with a 1 February 2027 date. ZATCA notifies taxpayers of their wave at least six months in advance, so treat notification as the trigger and plan the software work before it arrives.

How much does Arabic localisation add to a project?

It varies with interface complexity rather than word count, because the work is layout and data handling rather than translation. The controllable variable is timing: designing bilingual from the first sprint costs far less than converting a finished English product, which can require rewriting layout code and occasionally schema changes.

Is it cheaper to hire an offshore team or a Saudi-based one?

Offshore day rates are lower, but the comparison should include withholding tax on cross-border payments, VAT treatment, time-zone and language overhead, and whether the operating model later requires in-Kingdom staff subject to Saudisation quotas. Many organisations land on a blended model: offshore engineering capacity with in-Kingdom accountability for compliance, stakeholders and support.

What is a realistic first budget if I have no scope yet?

Fund a short discovery and architecture phase rather than a full build. Two to four weeks resolving data residency, ZATCA scope, integration count and the minimum shippable version converts a range into a number — considerably cheaper than finding those answers halfway through delivery.

Next steps

If you are budgeting a software project for the Kingdom, answer the residency and ZATCA questions above first — they determine architecture, and therefore cost. Our Saudi Arabia hub covers how we work with organisations in the Kingdom, and our Saudi PDPL compliance page sets out the technical implementation side — controls, records and architecture, delivered alongside your legal advisers rather than in place of them. For the build itself, see custom software development.

Sources and further reading: ZATCA e-invoicing roll-out phases, ITIF on Saudi Arabia's cross-border data transfer regulation, PwC on Saudi withholding taxes, AWS on its Saudi Arabia region, Google Cloud Dammam region access, and Clyde & Co on the 2026 Saudisation updates.

Written by the Stratgik team. Stratgik is a technology strategy and engineering firm headquartered in Gurugram, India, working with clients across India, the United States, the United Kingdom, Singapore, the UAE and Saudi Arabia. We are not a law firm or a tax advisor; regulatory obligations described here should be confirmed with qualified counsel.

Tell us what isn't working.

One process, one system, one decision you are stuck on. We will come back with how we would approach it, what it would take, and whether it needs building at all.

The Stratgik model

Strategy first. Technology that follows through.

Four stages, in order. Most businesses need them one at a time.