Custom software development in Saudi Arabia: ready-made or built for you, and what drives the cost

Buy ready-made software when a product covers most of your process through its settings alone. Connect AI or integrations when your systems work but your team retypes, reads or chases information between them. Build a system when the process is specific to your company and any product would need heavy workarounds. Many companies end up with a mix.

If you are weighing custom software development in Saudi Arabia, in another Gulf country, or from abroad for Saudi customers, the method is the same. Saudi rules such as data protection and e-invoicing are explained where they apply.

Three routes, not two

The usual framing is bespoke software vs off the shelf. A third route, connecting what you already have, often fits better.

Keep a ready-made product and configure it

Business systems are ordinary, and larger companies use more of them, at least in the EU, where 53% of enterprises with 10 or more employees used ERP, CRM and/or business-intelligence software in 2025, and ERP use ran from 41% of small enterprises to 89% of large ones [1]. The practical question is how to get such a system.

The UK government's guidance for its own technology purchases has criteria that travel well: buy when a product meets most of your needs, the supplier can configure its settings to suit you, you need little customisation or bespoke change, and your organisation can support it [2].

Watch out: the guidance warns that "Even small modifications to OTS software can remove most of the benefits of using it" [2]. Use the settings, and where the product's way of working is good enough, change your process to match.

Disclosure: O AI, which publishes this guide, makes a ready-made product itself, for one sector: Rushd, a practice-management platform for law firms.

Connect AI and integrations to what you already use

Keep the accounting system, CRM and WhatsApp you have, and add the missing piece: AI that reads documents or drafts replies, an integration between systems, or a report built from several sources.

It fits when the systems work but staff retype and copy between them, text-heavy work such as documents and replies is slow, or side spreadsheets bridge two tools. If AI is the missing piece, start with one repetitive task.

Watch out: every connection needs upkeep when either system changes. Check that each system has a documented way to exchange data, such as an API (an interface other software can call) or a reliable export.

Build a system around how you work

Building gives you "more control over your requirements and flexibility to adapt your processes" [2]. A build is worth pricing when:

• your need is unique or rare;
• available products cannot be adapted or integrated to meet your core needs;
• you need to own the software so you can keep changing it;
• you have the people and resources to manage the project.

Regional reasons count too: screens and documents designed for Arabic from the start, Hijri (Islamic calendar) and Gregorian dates side by side, or a link products lack to a local platform your work depends on, such as a government service or a local payment provider.

Watch out: a build is a product you now own. Budget for its life after launch, and name the person who will own it.

Buy what is common, connect what is missing, and build only what makes you different.

Build, buy or connect? A ten-question decision grid

Answer each question yes or no for one process at a time. Questions 1, 4, 5 and 6 follow the UK guidance [2], question 8 builds on it, and the others were added for this guide.

How to read your answers:

• Mostly "ready-made": shortlist two or three products and trial each on one hard case.
• A mix: a ready-made core with connections for the gaps, which is common.
• "Build" on questions 5 and 6, plus a yes on 8: a build is worth pricing.

If questions 1 and 5 both get a yes, start with the product and list the steps where it makes you work like everyone else. Those steps are what to connect or build later; the rest stays in the product.

These three examples are illustrations, not client stories.

Custom CRM in Saudi Arabia, or a ready-made one?

A spare-parts distributor in Riyadh tracks leads in Excel and WhatsApp, and its customers write in Arabic. It answers yes to questions 1, 2 and 3, so the route is a ready-made CRM with Arabic support, configured, plus a WhatsApp connection. Nothing needs building yet.

The cost to count is messages. Meta has charged per delivered template message (pre-approved messages a business can send first, such as offers) since 1 July 2025, at rates that vary by template category and the recipient's country calling code [3]. Since 1 October 2026 it also charges per message for replies your staff or a third-party AI send inside the 24-hour customer-service window [4]. Estimate both monthly volumes, and check current rates and any free allowance before you connect.

An ERP that works, and paper everywhere else

A contracting company in Dammam runs a ready-made ERP that issues its invoices. Site reports, material requests and approvals travel on paper and WhatsApp.

The ERP answers yes to question 1: keep it. For the site work, ask question 1 again, because field-reporting products exist. If one covers your reports and approvals and can feed the ERP, configure and connect it (question 3). Build a small app only if your approval chain is specific to how you run sites (question 5) and someone will own it (question 8).

Leave the accounting side alone. Saudi e-invoicing's integration phase, rolled out to taxpayers in waves, integrates their invoicing solutions with the systems of ZATCA, the Zakat, Tax and Customs Authority [5]. ZATCA's FAQ says the technical requirements are typically implemented by solution providers or by "the internal technical teams for in-house built solutions" [6]. Keep a product that already meets them, and most of that work stays with its supplier.

Saudi customers, systems abroad

A Dubai distributor, or a European manufacturer with a new Riyadh office, runs a global CRM in English. Saudi customers write in Arabic, and local staff keep a side spreadsheet. The core answers yes to question 1 and the Arabic gap yes to question 7, so keep the global system and connect an Arabic tool for taking in requests and replying. Build only if the Saudi process differs from the rest of the business.

Those customers' names and phone numbers are personal data [7, Art. 1] under Saudi Arabia's Personal Data Protection Law (PDPL), which covers processing of data about individuals residing in the Kingdom "from any party outside the Kingdom" [7, Art. 2].

What drives the cost of custom software development in Saudi Arabia

Ten drivers shape software development cost in Saudi Arabia and anywhere else: roles and workflow steps, screens and reports, integrations, Arabic and bilingual work, data migration, platforms, security and privacy, regulated outputs, AI features, and support after launch. Published price guides rarely cite a source, and a price only means something next to a scope, which is why O AI does not publish prices for custom work.

The platforms row applies to app development cost too: each platform adds its own build, testing and updates, plus a store release for phone apps, even when much of the code is shared.

When quotes arrive:

• ask for each one itemised against these drivers;
• ask what is excluded, such as hosting, usage fees, tax and support after the warranty;
• ask who will own the source code, your data and the business rules, and get it in the contract;
• compare only quotes whose scopes match.

Running costs people forget, and a three-year worksheet

A quote covers the start. The worksheet below adds the lines that keep coming, from licences that grow with headcount and usage fees (see the CRM example) to, one day, the cost of leaving.

The UK guidance asks buyers to "aim to understand as much of the full cost of building or buying a product as possible", across its whole lifecycle [2]. Copy this worksheet and fill in one column per route.

Fill every cell from a written quote or your own measurement. Two lines need care. On Y1, use the users you expect in year three, and ask each supplier in writing how prices change at renewal. On Y5, multiply the owner's monthly hours by their hourly cost and by 12; for a build, include the time to decide and test each change.

Then set the total against what the process costs today (work out what the task costs you now). Three years is only a horizon for comparison, so use it for every route.

Data protection duties apply on every route

This article is general information, not legal advice. Check your company's obligations against the current text of the law and its implementing regulations.

When a supplier holds or processes your data

This covers product vendors, connected tools and any developer who hosts or supports your system. PDPL Article 8 says the controller (the party that decides why and how data is processed; usually your company) "shall only select Processors providing the necessary guarantees" and must monitor their compliance [7]. Under the PDPL's Implementing Regulation, issued by SDAIA (the Saudi Data & AI Authority), the processor agreement must include, among other points [8, Art. 17]:

• the purpose of the processing, the categories of data and how long processing lasts;
• notice to you, without undue delay, if a breach occurs;
• whether the processor is subject to other countries' regulations;
• any subcontractors, or other parties who will receive the data.

Ask every shortlisted supplier about each point, in writing.

When you build

The system must let you meet your own duties, so write them into the first scope. Article 19 requires security measures, "including during the Transfer of Personal Data" [7]. Article 18 requires personal data to be destroyed "without undue delay" once no longer needed for its purpose, with exceptions: data that can no longer identify anyone may be kept, and data must be kept where a legal basis sets a retention period [7]. That means roles and access rights, an audit log, export and deletion, and retention settings, priced in the first quote.

When customers or data cross borders

Article 2 reaches processing "from any party outside the Kingdom" [7], so a company in Dubai, London or Cairo that processes personal data about residents of the Kingdom is in scope.

If personal data leaves the Kingdom, Article 29 sets conditions, including an adequate level of protection and limiting the transfer "to the minimum amount of Personal Data needed" [7]. SDAIA's Transfer Regulation sets out cases in which a company may transfer without meeting those two conditions, using safeguards such as standard contractual clauses [9].

For the wider Gulf: according to the UAE Government portal, the UAE's federal data protection law (Federal Decree-Law No. 45 of 2021) applies to processing "inside or outside the country", and the Dubai International Financial Centre (DIFC) has its own, DIFC Law No. 5 of 2020 [10]. Check the rules of every country where your customers live.

What to prepare before the first meeting: a one-page brief

You do not need a full business requirements document (BRD) or software requirements specification (SRS) before the first meeting; a good developer should help you write those. One page that describes the problem, and what it costs you now, is enough to start.

Bring the same page to every supplier, so every proposal answers it and can be compared line by line.

Start with a pilot that can move to production

Whichever route you take, test it on real work before everyone depends on it.

• Ready-made: ask for a trial. The UK guidance suggests you "try to solve one small but hard problem", test integration with your current products, and test it with the people who will use it [2].
• Connect or build: the first release covers one process for one team, with real data. Before it starts, agree in writing what "ready for everyone" means: a named owner, the error rate you accept, a target time per case, data rules met, and support in place.

At the end of a fixed period, decide: roll out, fix and re-run, or stop. For an AI task, a two-week pilot plan sets out the steps.

Your next step

This week:

1. Pick one process.
2. Answer the ten grid questions for it.
3. Fill in lines 1 to 3 of the one-page brief.

If you want a second opinion: we are O AI, a Saudi AI and software company in Al Khobar. We connect AI to the systems and channels you already run, and when no ready-made product fits, we design and build the system, platform or app around how you work. Whichever supplier you talk to, us included, ask which of the three routes they would rule out for you, and why.

This is how we work: a written scope of work, a published timeline, and payments tied to delivery milestones. Every stage is approved before the next one begins, and interfaces are approved before code is written. After launch come a warranty period, technical support and optional maintenance packages. We work with companies anywhere in Saudi Arabia, remotely in Arabic or English, and are open to projects from the GCC (Gulf Cooperation Council) countries and beyond.

Bring your one-page brief to a free consultation, and we will look at which route fits, with no commitment. We reply within one business day.