Web Development in Riyadh for Government, Enterprise and E-Commerce

Why Riyadh web development requires Arabic-first design and Saudi ecosystem integration

Saudi Arabia is digitising rapidly, and every digitisation initiative needs a web platform. The government mandates electronic invoicing through ZATCA (Zakat, Tax and Customs Authority): every Saudi business above a revenue threshold must generate, transmit and store invoices electronically through web-based systems. Nafath, the national digital identity platform, provides single sign-on for government and private services. SADAD handles bill payment. Absher provides citizen identity verification. Muqeem manages expatriate services. Each of these platforms exposes APIs that Saudi web applications must integrate with, creating a web development ecosystem unlike anywhere else.

Building a web application for the Saudi market is not the same as building one for a global audience and translating it to Arabic. Arabic is a right-to-left language, and proper RTL support goes far beyond flipping the CSS direction property. Navigation flows right-to-left. Tables read right-to-left. Charts and data visualisations need mirrored axes. Phone number inputs need to handle both Arabic-Indic numerals and Western Arabic numerals. Date pickers need to support both Hijri and Gregorian calendars, as Saudi government services primarily use Hijri. Form validation must handle Arabic text, Saudi mobile numbers (+966), Saudi national ID numbers (10-digit starting with 1 for citizens, 2 for residents) and commercial registration numbers.

Most web development agencies treat Arabic as a language variant of an English-first design. Saudi users notice immediately: the interface feels awkward, text alignment is inconsistent, and cultural design conventions feel foreign. Riyadh web development must be Arabic-first: designed for RTL from the wireframe stage, with English as the secondary language.

What we build for Riyadh organisations

Government digital services

The Digital Government Authority (DGA) coordinates the digitisation of government services. Ministries, agencies and government entities are rebuilding citizen-facing portals on modern web platforms, replacing legacy systems with responsive, mobile-first, Nafath-integrated web applications. We build portals for service delivery, open data publication, internal digital workplace and compliance dashboards.

Enterprise web applications

Saudi companies need HR self-service (integrating with GOSI for social insurance, Mudad for wage protection, Qiwa for labour compliance), procurement portals (Etimad-integrated for government contractors), customer portals (Arabic-first B2B and B2C), and compliance dashboards (ZATCA e-invoicing monitoring, SAMA regulatory reporting for financial institutions).

E-commerce platforms

Saudi e-commerce is a growing market. Local platforms compete with Noon, Amazon.sa and Jarir Online. New entrants need web platforms handling Arabic product catalogue management (with Arabic product descriptions, Arabic search and Arabic filtering), SADAD and mada payment integration (mada is the national debit network used for the majority of card transactions in Saudi), and Aramex/SMSA/DHL last-mile delivery integration (with Arabic tracking pages and Arabic shipping notifications). The Saudi web development talent market is constrained: the country needs additional web developers to meet Vision 2030 digitisation timelines, creating strong demand for external development partners.

Technology stack

We build Saudi web platforms primarily on Next.js (React server components for Arabic SEO, static generation for performance, API routes for Saudi integration endpoints), with Tailwind CSS (RTL-first configuration using CSS logical properties), and PostgreSQL or Supabase for data persistence. For deployment, we use Vercel or AWS (Bahrain region, me-south-1) depending on data residency requirements. The Bahrain region provides low-latency access for Saudi users. Note that hosting in AWS Bahrain does not automatically guarantee Saudi data-sovereignty compliance; hosting location should be selected based on the specific regulatory and contractual requirements of each project.

How we deliver Riyadh web projects

Arabic-first design and development

We design in RTL, not in LTR and then flip. The wireframe is Arabic. The component library is RTL-native. Spacing, alignment, icon direction and navigation flow are designed for Arabic readers. When English is needed, we add LTR support as the secondary direction. We use CSS logical properties (margin-inline-start, padding-inline-end) rather than directional properties to make the codebase direction-agnostic.

We select Arabic web fonts optimised for screen readability (Noto Sans Arabic, IBM Plex Arabic or Tajawal for modern interfaces; Amiri or Scheherazade for formal/government contexts). Arabic line height, letter spacing and paragraph sizing differ from Latin typography, and we calibrate these specifically rather than using default browser Arabic rendering.

Form validation for Saudi data formats

Saudi web applications require form validation handling Arabic text input, Saudi mobile numbers (+966 followed by 9 digits), Saudi national ID numbers (10-digit starting with 1 for citizens, 2 for residents), commercial registration numbers, and both Arabic-Indic numerals and Western Arabic numerals. Phone number inputs need to accept both numeral systems transparently. Address fields need to handle Arabic address formats, which differ structurally from Western address conventions.

Hijri calendar support

Saudi government services use Hijri dates (Umm al-Qura calendar). Our date components support Hijri date display and input, Hijri-Gregorian conversion, and dual-calendar display (showing both dates simultaneously, common in Saudi business contexts). We use the Intl.DateTimeFormat API with the "islamic-umalqura" calendar.

Saudi platform integration

Nafath authentication: We integrate with the Nafath digital identity platform for Saudi citizen and resident authentication. Nafath uses a random number challenge-response mechanism. Our integration handles the OAuth2/OIDC flow, session management after authentication, and graceful fallback for non-Nafath users.

ZATCA e-invoicing: Saudi businesses must generate XML invoices compliant with ZATCA's FATOORA standards (based on UBL 2.1 and UN/CEFACT), digitally sign them using ZATCA-issued cryptographic stamps, and transmit them in real-time (Phase 2). We build web applications with ZATCA integration for invoice generation, signing, transmission and status tracking.

Payment integration: Saudi payment methods include mada (the national debit network handling the majority of card transactions), Apple Pay and Google Pay (growing rapidly in Saudi), SADAD (bill payment required for government-related payments), STC Pay (mobile wallet with millions of users), and Tamara/Tabby (buy-now-pay-later, increasingly expected by Saudi consumers for e-commerce). We integrate with payment gateways (HyperPay, Moyasar, PayTabs) that aggregate these methods into a single integration point, enabling the full Saudi payment stack without multiple direct integrations.

Cost and timeline

Web development in Riyadh ranges by platform complexity and Saudi ecosystem integration requirements. These ranges come from our published web app development cost guide.

Our published web app development cost guide provides USD ranges by complexity:

Riyadh projects add cost drivers including Arabic-first RTL design, Nafath authentication, ZATCA e-invoicing integration, Saudi payment methods (mada, SADAD), and Hijri calendar support. Timelines: corporate bilingual sites 4 to 6 weeks; single-purpose applications 6 to 10 weeks; enterprise platforms 12 to 16 weeks.

Choosing a Riyadh web development partner

When ZTABS is not the right fit

• Arabic content writing and translation as the primary deliverable. We build the bilingual platform; Arabic content creation requires native Arabic writers with Saudi market knowledge.
• Government IT infrastructure (networking, server hardware, on-premise deployments) as the primary deliverable. We build the web applications; infrastructure is a separate engagement.
• Ongoing digital marketing, SEO and social media management is scoped separately. See our digital marketing services.
• SAP or Oracle ERP implementation as the primary deliverable. We integrate web portals with ERP systems; the ERP implementation is a separate project.

Risks that delay Riyadh web projects

• Arabic RTL treated as a CSS flip. Proper RTL goes beyond CSS direction. Navigation, tables, charts, number formatting and form validation all need RTL-native implementation. A site built LTR and flipped produces an interface that Arabic users find awkward. We design Arabic-first from the wireframe.

• Nafath integration underestimated. Nafath's challenge-response flow, token management and edge cases (downtime, expired sessions, non-Nafath users) require dedicated development time. Treating it as a simple OAuth redirect creates authentication failures in production. We prototype Nafath integration in the first sprint.

• ZATCA Phase 2 compliance gaps. Phase 2 (integration phase) requires real-time XML transmission with cryptographic signing. A web application that generates invoices but does not transmit them in real-time to ZATCA creates compliance risk. We implement the full ZATCA flow including signing, transmission and status tracking.

• Hijri calendar edge cases. Saudi government services use Hijri dates. A date picker that only supports Gregorian or converts incorrectly between Hijri and Gregorian causes data entry errors. We use standards-compliant Hijri support through the Intl API.

• Mobile performance on Saudi networks. Saudi mobile internet penetration is high. A web application optimised for desktop broadband but slow on mobile creates poor user experience for the majority of Saudi users. We design and test mobile-first, with Arabic font loading strategy using font-display: swap and size-adjusted fallbacks to prevent layout shift during Arabic font loading.

• Saudisation and localisation expectations. Saudi users expect web applications that reflect Saudi cultural conventions: formal Arabic language for government and business contexts, Hijri calendar dates displayed alongside Gregorian, SAR currency formatting with Arabic numeral options, and design elements that respect Saudi aesthetic preferences. A web application that feels generic or "translated from English" does not meet Saudi market expectations.

How Saudi web development differs from other GCC markets

Building web applications for Riyadh differs from building for Dubai or Abu Dhabi in several important ways. Saudi Arabia has its own digital identity platform (Nafath), its own e-invoicing mandate (ZATCA FATOORA), its own payment debit network (mada), and its own government digital standards (DGA). A web development team experienced with Dubai's payment methods (HyperPay with Tabby) but unfamiliar with Saudi-specific platforms (Nafath, ZATCA, SADAD, mada) will underdeliver.

Calendar: Saudi government services primarily use the Hijri calendar, requiring dual-calendar support throughout the application. Dubai and Abu Dhabi primarily use the Gregorian calendar with Hijri dates for Islamic observances. Language: both markets require Arabic-English bilingual support, but Saudi Arabic differs from UAE Arabic in terminology, formality level and cultural conventions. Saudi government portals use formal Modern Standard Arabic (Fusha), while UAE consumer platforms may use a more conversational register. Regulatory: Saudi data protection follows PDPL (Personal Data Protection Law, 2023), while the UAE follows Federal Decree-Law No. 45. Saudi and UAE e-commerce follow different regulatory frameworks and licensing requirements.

Questions to ask before hiring a Riyadh web development team

1. Do you design Arabic-first or flip from English? The answer reveals whether the team has genuine Arabic UX expertise. Arabic-first produces natural interfaces; English-first produces awkward ones.

2. Have you integrated with Nafath? Ask about the OAuth2/OIDC flow, challenge-response mechanism and edge case handling. A team unfamiliar with Nafath will underestimate the integration.

3. Can you implement ZATCA FATOORA e-invoicing? Ask about XML generation, cryptographic signing and real-time transmission. Phase 2 compliance requires all three.

4. Do you support Hijri calendar dates? Ask how they implement Hijri-Gregorian conversion and dual-calendar display. A team that does not know the Intl.DateTimeFormat API with islamic-umalqura will produce custom date logic that fails on edge cases.

5. Where will the application be hosted? Ask about data residency options (AWS Bahrain me-south-1 for low-latency Gulf access, local sovereign hosting for government projects with specific requirements). Hosting in a particular region does not automatically satisfy all data-sovereignty obligations; evaluate against PDPL (Personal Data Protection Law, 2023) and project-specific regulatory requirements.

Next step