A Saudi business that needs its own app (a booking system for a clinic in Riyadh, a portal for a contractor's clients in Jeddah, an internal tool for a distributor in Dammam) usually hits the same requirement in the first meeting: it has to work properly in Arabic and in English. Customers and most staff read Arabic first, some managers, suppliers and expat staff work in English, and government-facing documents are Arabic.

That one requirement changes the decision more than people expect. Plenty of software "supports Arabic" in the sense that it can display Arabic letters. Far less of it is designed Arabic-first, with English as a true second language rather than the other way round.

This guide is about how to choose who builds that app. There are three realistic routes, each right for a different kind of business. I work at Mythex, an AI app builder made in Dubai, and Mythex is one of the options in route three; I've kept the checklists usable whichever route you pick.

First, write down what "bilingual" means for you

Before you talk to anyone, answer these five questions on one page. They decide which route fits and they make every quote comparable.

  1. Who uses each language? For example: customers book in Arabic or English, reception works in Arabic, the owner reads reports in English. If customers only ever see Arabic, you may need an Arabic-only customer side and a bilingual back office, which is simpler.
  2. Which language is the default? For most Saudi customer-facing apps, Arabic should open first, with a visible switch to English. The default affects layout, the order of fields on printouts and what search engines index.
  3. What has to be in Arabic by law or by habit? Invoices, contracts, receipts and anything sent to a government platform. Note them now so nobody discovers it at launch.
  4. What data do you hold? Names, national ID or Iqama numbers, health or financial details. This decides how seriously you take hosting and access (more on PDPL below).
  5. What does it connect to? Payments (mada, Apple Pay, instalment providers such as Tabby or Tamara), WhatsApp, your accounting or ZATCA e-invoicing tool, a government platform. Each connection is where projects slip.

If you can't answer these yet, any quote you get is a guess.

Route 1: A software agency

A Saudi or regional agency designs and builds the app for you, usually with a project manager, a designer and developers.

Best for: apps that are central to the business, need deep integrations (a government platform, a core banking or ERP system), or have strict data rules that need in-Kingdom hosting and formal security reviews.

Watch for:

  • Arabic designed last. Ask to see two apps they've shipped in Arabic and English, and open them on your phone in both languages. Look at forms, tables and dates, not just the home page. If Arabic looks like a mirrored English design with awkward spacing, that's what you'll get.
  • Who owns the code and the hosting account. Get the source code, the database and the cloud account in your company's name, in writing.
  • The cost of change after launch. Most of an app's life is changes. Ask for the day rate for small changes and how quickly a typical one is delivered.
  • A fixed scope that hides the real one. If the quote is a single number for "the app", ask for it split by screen or feature, so you can drop items.

Quotes vary widely with scope, so compare them only against the same one-page brief.

Route 2: A ready-made product (SaaS)

A subscription product built for your type of business: clinic software, a salon booking tool, a property management system, a field service app.

Best for: businesses whose process looks like everyone else's in their industry, where speed matters more than fit.

Watch for:

  • Arabic quality on the screens your staff use most. Many international products translate the customer-facing screens and leave the admin side in English, or translate it badly. Ask for a trial and have your receptionist or coordinator use it in Arabic for a day.
  • Saudi specifics. ZATCA-compliant invoices or a link to your e-invoicing tool, mada through a local payment provider, Saudi phone formats, and printouts that are correct in Arabic.
  • The price in year two. Per-user or per-branch pricing is fine at one branch and painful at four. Ask for the price at your size in two years.
  • The 20% that doesn't fit. Every packaged product has a part of your process it doesn't handle. Find out what it is during the trial, not after.

Route 3: Build it yourself with an AI app builder

You describe the app in plain language, and an AI app builder writes the code, gives it a database, and publishes it. Someone in the business (an operations manager, the owner, a capable coordinator) owns it rather than a developer.

Best for: internal tools, portals, booking and intake systems, and anything where your process is specific to you and a packaged product would force you to change it. Also for testing an idea before paying an agency to build the full version.

Watch for:

  • Whether the builder itself works in Arabic. Can you write the request in Arabic? Does it produce right-to-left layouts properly, or do you have to fix them by hand? Most global builders don't document Arabic or RTL support; test with your own screens.
  • Where the app and its data live. Ask each builder where apps and databases are hosted. Mythex, for example, does not host inside Saudi Arabia today, so it isn't the right choice for data that has to stay in the Kingdom.
  • Who maintains it. A builder makes changes cheap, but somebody still has to own the app: decide who.
  • Honest scope. These tools are strong at web apps with forms, tables, dashboards, bookings and portals. A heavily regulated system or a deep integration with a government platform is still agency work.

PDPL: the question to ask in every route

Saudi Arabia's Personal Data Protection Law (PDPL) has been fully enforced since September 2024. It sets rules on collecting, using and transferring personal data, including transfers outside the Kingdom. I'm not a lawyer and this isn't legal advice, but in practice three questions cover most small and mid-size apps:

  • Where is the app hosted, and where is the database?
  • Who at the vendor can see our data, and is that logged?
  • Can we export all our data and delete it when we leave?

For sensitive data (health, financial, national ID numbers in bulk), get proper legal advice before you choose. For a booking page or an internal stock tracker with business contacts, the answers above are usually enough to decide.

A short build: what route 3 looks like in practice

To make route 3 concrete, here is a bilingual service-request portal for a small facilities company in Riyadh, built in Mythex. The same steps work for most portals.

Prompt 1, the app:

Build a bilingual Arabic and English service-request portal for a facilities maintenance company in Riyadh. Arabic is the default with a right-to-left layout, and a language switch in the header. Clients log a request with: building, unit, category (AC, plumbing, electrical, cleaning), description, photos and preferred visit time. Staff see all requests in a table with status (new, assigned, visited, closed) and can assign a technician.

Prompt 2, the details that make it Saudi:

Phone numbers use the +966 format and are validated. Show dates in the Gregorian calendar with the Hijri date next to it on request details. Use Western digits in tables but keep Arabic text for all labels. Add a printable visit report in Arabic with the company's VAT number in the footer.

Prompt 3, the people:

Add three roles: client (sees only their own building's requests), coordinator (sees and assigns everything), technician (sees only requests assigned to them, can upload after-visit photos and close the request).

A Mythex app preview shown at phone size, used to check the Arabic layout on a small screen

Then switch the preview to phone size and check the Arabic layout on the screens your clients will actually use. Fix what's off in plain words ("the status badge overlaps the building name in Arabic on mobile") rather than by editing code.

What you end up with is a working web app with its own Postgres database, photo storage, sign-in for the three roles (built by the agent when you ask for it), and a public URL. On Pro you can put it on your own domain, and turn it into Android and iPhone apps through Google Play testing and TestFlight.

Honest limits of the build-it-yourself route

  • Hosting location. As above: if your data must stay in Saudi Arabia, this route (with Mythex at least) isn't for that app today.
  • Payments and government platforms. You can connect a payment provider that supports mada with your own keys, but you still sign up with the provider yourself. Deep links to government platforms are usually agency territory.
  • Translation quality is still your job. The builder writes the Arabic and English text, but someone fluent should read every label once, especially legal or medical wording.
  • Ownership. A portal nobody owns decays. Pick the person who will make changes before you start.

For teams

If several people will build or maintain internal apps, keep them in a shared team workspace rather than one person's account, so the app doesn't leave when an employee does. On Mythex that's the Business plan (from $50/month): a shared workspace, roles (admin, editor, viewer), members-only apps that only signed-in colleagues can open, and Google Workspace sign-in with your company domain. Saudi-specific notes and how other builders compare are in our guide to AI app builders in Saudi Arabia, and plans are on the pricing page.

How to decide in one sentence each

  • Choose an agency if the app is core to the business, connects deeply to government or banking systems, or must be hosted in the Kingdom.
  • Choose a ready-made product if your process is standard for your industry and the product's Arabic holds up when your own staff use it for a day.
  • Build it yourself if the app is specific to how you work, the data isn't the sensitive kind, and someone in the business is willing to own it.

Whichever you choose, start from the one-page brief. It's the cheapest hour you'll spend on the project.