Web platform development in Saudi Arabia: what to settle first

You are planning a web platform in Riyadh, or a company already working in the Gulf and now selling in Saudi Arabia. Customers will sign in, order, book or pay, and your staff will run it behind the scenes. Before you compare web platform development companies, a few decisions shape the whole build, and they are easy to settle early and slow to change late. MobiStack Digital takes over, fixes and builds mobile apps and web platforms, and this is what we would settle first and how we would ask any team about it. It is not legal or tax advice: your lawyer and your accountant answer for your case.

In short

• Start in Arabic. Arabic needs a true right to left layout and text written by a native reader. Planned from the first screen, it is far easier than a flip at the end.
• Know what personal data you will hold. Saudi Arabia’s Personal Data Protection Law (PDPL) covers how you collect, use and store data about people. Decide where it lives, how consent is recorded and who can see it.
• Check whether the platform issues tax invoices. If it does, the Zakat, Tax and Customs Authority (ZATCA) has rules for how e-invoices are made. Your accountant tells you which ones apply to your business.
• Choose payments and ownership early. Pick the ways your customers pay, and keep the code, hosting and logins in your company’s name from the first day.

What kind of web platform are you planning?

A web platform is software that people use, not pages they read. Customers or staff sign in, place orders, book, pay or track something, and your team manages it in the background. If you are still deciding between a website and a platform, our post on web development in Beirut explains the difference. It applies in Riyadh as well.

Everything below applies once you know you need a platform: a customer portal, a marketplace, a booking system or an operations dashboard. A good team will ask what the business has to do first, and only then talk about screens. For the places we work in and the way we do it, see our Middle East page and our web platform development page.

Why settle Arabic and right to left first?

Settle Arabic first because it changes the layout, the text and the data, and it is hard to add late. A right to left platform mirrors its screens, so navigation, forms, icons with a direction and animations all have to be designed for it. Each language also needs text written by someone who reads it natively, not a translation tool.

Four questions to put to a team:

1. Is Arabic the main language, or a second one that follows English?
2. Who writes the Arabic, and who reviews it before it ships?
3. Is the layout designed right to left on purpose, with mixed Arabic and English lines tested?
4. How are names, addresses, dates and numbers stored and shown in both languages?

For invoices, ZATCA’s e-invoicing FAQ (opens in a new tab) says the human readable invoice can be in any language, as long as it also includes Arabic. So even a platform that starts in English needs Arabic where invoices are concerned. Our post on how to judge a UI/UX agency from its portfolio shows what to look for in right to left work.

What does the Personal Data Protection Law mean for a platform?

The PDPL covers personal data about people in Saudi Arabia, and the platform you build will hold a lot of it: names, phone numbers, addresses, order history. In practice, you decide before design what data you collect, why, where it is stored, who inside your company can see it, and how a customer’s consent is recorded and withdrawn.

Three points an owner can take from the law’s official text, published by the Saudi Data and AI Authority (SDAIA) on its data protection page (opens in a new tab) and as a PDF of the law (opens in a new tab):

• Scope. The law covers processing of personal data in the Kingdom, and processing of data about people residing there, including when the processing happens outside it. A Gulf company selling in Saudi Arabia from another country should read it as applying to its platform.
• Consent. Processing personal data generally needs the person’s consent, with exceptions the law lists, and a person can withdraw it. The platform needs a way to record consent and to act when someone withdraws it.
• Transfers. The law has rules for sending personal data outside the Kingdom, and SDAIA publishes its own rules on them. Where your hosting runs, and which services your platform sends data to, are decisions to write down.

The rules also change. Ask your team to check SDAIA’s current text on the day you sign, not a copy from a blog, and ask your lawyer what applies to your business. Then ask the team how its design lets you answer: can you export one customer’s data, delete it, and see who looked at it? These are product features, and they are far easier to build in the first version than to add once the platform is live. Our post on what goes into the first version of an app explains how to decide what comes first.

Does your platform need to issue e-invoices?

If your business is a taxpayer in Saudi Arabia and the platform sends invoices to customers, ZATCA’s e-invoicing rules apply, and the platform has to make the invoices the way ZATCA requires. ZATCA’s roll-out phases page (opens in a new tab) describes two phases: a generation phase, introduced on 4 December 2021, and an integration phase that reaches taxpayers in groups, called waves.

What this means for a platform build:

• The generation phase asks taxpayers to stop issuing handwritten or text-editor invoices and to use an e-invoicing solution that follows ZATCA’s rules. If your platform issues invoices, it is that solution, or it connects to one.
• The integration phase adds a connection between your solution and ZATCA’s platform. ZATCA tells each group of taxpayers before its date, so ask your accountant whether your business has been told, and plan for it either way.
• Invoices are part of the product. The fields, the format and the Arabic text are built into the platform, and they are tested like any other feature.

ZATCA’s dates and groups change over time. Quote them only from ZATCA’s own pages, and ask the team to do the same. If the platform never issues an invoice, because a separate accounting system does, say so in the first conversation, so that nobody builds what you do not need.

Which payments should it accept?

Accept the ways your customers already pay, and ask which of them your payment provider supports. A platform that offers only a card form can lose customers who prefer a local card or a wallet, and the checkout flow, refunds and reports all depend on the methods you choose.

Ask the team:

• Which ways to pay do our customers use today, and which must the platform support on the first day?
• Who confirms that a payment arrived, and what happens when one fails or is refunded?
• Which account receives the money? It should be registered to your company.
• Does the payment provider’s own documentation confirm each method? Check it yourself, as methods and rules differ from one provider to the next.

A payment that does not match its order is a business problem, so a good team plans for failures and refunds before launch, and tests them.

Who should own the hosting, the code and the accounts?

Your company should own all of them. The domain is registered to your company, the hosting runs in an account in your company’s name, the code sits in a repository your company owns, and each person on the team has their own login that you can remove. That is the same rule we give for a platform anywhere, and in Saudi Arabia it also helps with the data questions above: you can say where the data lives, because you hold the account it lives in.

We keep code, accounts and store listings in your name. Our office is in Dubai, and our team works remotely in Beirut, so the platform is built for you remotely. That makes written ownership, a clear audit trail and agreed working hours more important, not less. Our post on hiring app developers in Dubai goes through who builds it and who owns it, and the same questions apply here. If a platform already exists and the team behind it has gone quiet, read taking over an app from another developer: a takeover starts with a written audit.

How do you ask any team about all this?

Ask every team the same five questions, in writing, and compare the answers side by side. A team that has built for this market will answer in specifics. A team that answers with “yes, of course” has not told you anything you can check.

On our side, our developers build with AI and review every line. Every change passes automated tests and automated code review, and one of our developers reads it before it ships. A change nobody read does not ship. Our post on whether code written with AI is safe explains how that works.

Questions owners ask

Does a platform for Saudi customers have to be hosted in Saudi Arabia?

We cannot give you a legal answer, and it depends on the data and on your sector. The PDPL has rules for sending personal data outside the Kingdom, and some sectors have their own. Ask your lawyer, then ask the team to build so that where the data is hosted is a decision you can change, not a rewrite.

Can the platform start in English and add Arabic later?

It can, if it is built for both from the start: layouts that mirror, text that can be translated, and storage that handles both scripts. The hard case is a platform designed only for English and then forced into Arabic. If your customers read Arabic, begin there, or at least design the first screens in both.

Do we need e-invoicing if we only take payments through the platform?

It depends on whether your business issues tax invoices and on how ZATCA applies its rules to you, so ask your accountant. If the answer is yes, tell the team in the first conversation, because invoices are built into the platform, not added on top.

Which payment methods should a Saudi platform support?

The ones your customers use today. Look at how they pay you now, ask which of those your payment provider supports, and confirm each one in the provider’s own documentation. Start with the methods that cover most of your customers and add the others as the platform grows.

Can you take over a web platform someone else built?

Yes. A takeover starts with a written audit of the code, the accounts, the data and the risks, before anything is changed. We plan the move with you: code, accounts and hosting, set up in your name. Our post on whether to rebuild your app from scratch shows how we decide between fixing and starting again.

Planning a platform for Saudi Arabia?

Book a free 45-minute consultation. We go through your product before the call. We have been building products since 2021, and products our team has built are used by more than a million people.

Book a free consultation