Every software company in the Gulf claims senior engineers and on-time delivery. The questions that actually separate a safe choice from an expensive one are about proof, security, language, pricing and what happens after launch. Here are the twelve we would ask if we were the buyer.
Custom software is one of the few purchases where the product does not exist when you sign. You are buying a team, a process and a set of promises, and the brochure looks the same from a two-person studio and a two-hundred-person firm. The questions below are the ones that surface the difference, drawn from the conversations we have with buyers in Riyadh, Dubai and Cairo, including the ones where we were not the right fit.
1. Show me a named client and a delivered project
Anonymous case studies are easy to write. A named client, with a description of what was built and a client who agreed to be named, is not. Ask for at least one, and ask whether you can speak to them. A company that cannot name a single client in your region either has no delivered work there or has clients who would rather not be associated with it. Both answers matter.
2. Who exactly will work on my project?
The people in the sales meeting are rarely the people who write the code. Ask for the names and seniority of the engineers who will be assigned, how many other projects they carry at the same time, and who your single point of contact is when something goes wrong at 4 pm on a Thursday. Vague answers here become vague delivery later.
3. How is your information security independently verified?
A custom system will hold your customer data, your financial records and often your competitive process. The honest test is not a security page on the website but an independent audit. ISO/IEC 27001 certification means an external auditor has examined how the company controls access, handles incidents and protects client data, and keeps examining it every year. Ask for the certificate number and where it can be verified. If the answer is a policy document instead, weigh that accordingly.
4. Do you build in Arabic and English as standard?
In Saudi Arabia and the UAE, bilingual is not a feature, it is the baseline. Ask whether right-to-left layouts, Arabic data entry, mixed-language documents and Arabic reporting are part of the standard build or a paid add-on scheduled for phase two. Then ask to see a bilingual product the company has already shipped. Retrofitting RTL onto a finished English product costs more than building it in from the start.
5. How do you price, and what happens when the scope moves?
There are two honest models. Fixed scope with milestone payments gives you a known price and puts the estimating risk on the vendor, which is why good vendors insist on a paid discovery sprint before quoting. Time and materials gives you flexibility and puts the risk on you. Both work. What does not work is a fixed price quoted from a one-page brief, because the number is either padded or wrong. Ask how change requests are priced and approved, in writing.
6. Who owns the code and the data?
You should own the source code, the database schema and the data, with the right to take them to another vendor. Ask about licences for any third-party components and whether any part of the system depends on the vendor’s proprietary platform in a way that would trap you. A contract that leaves the intellectual property with the vendor is a subscription with a different name.
7. Are you ready for e-invoicing and VAT in my country?
Any system that issues invoices in Saudi Arabia has to meet ZATCA Phase 2 requirements, and in the UAE it has to produce data the accredited service provider can transmit. Ask whether the company has integrated with ZATCA Fatoora before, whether it understands the UAE Peppol model, and how VAT treatments are handled at line level. A vendor who has not heard of these is going to learn on your budget.
8. Where will the system be hosted, and who manages it?
Data residency matters to Saudi and UAE regulators and to many of your own customers. Ask which cloud regions the company works in, whether it can deploy into your own Azure or AWS tenancy, and whether it designs the infrastructure itself or hands you a container and a good-luck email. A company that has built and hardened cloud environments for financial workloads can answer this in detail.
9. What does your process look like between the kickoff and the launch?
- A discovery phase that produces a written scope, a data model and a prioritised backlog before anyone builds
- Working software you can see at regular intervals, not a reveal at the end
- Automated testing, a staging environment that mirrors production and a documented release process
- User acceptance testing with your team, with time for the changes it will surface
- A go-live plan with data migration, training and a rollback path
10. What happens after launch?
Software is not finished at launch. Ask what the warranty period covers, what a support agreement costs, what response times are committed to for critical issues, and whether the same engineers who built the system will support it. A company that offers managed services alongside development can keep one accountable team on your system for years, which is worth more than a slightly lower build price.
11. Can you show me your own product?
A company that runs its own software platform in production has learned things a project shop never does: how systems behave under real users, what breaks at 2 am, how to handle upgrades without downtime. Ask whether the company has a product of its own, and use it as evidence of how it builds.
12. Will you tell me when I am wrong?
The most valuable thing a software partner does is push back: on a feature that will not pay for itself, on a deadline that will break quality, on a replacement that should have been an integration. In the first meetings, watch whether the company agrees with everything you say. Enthusiastic agreement is a sales technique. Considered disagreement is engineering.
You are not buying software. You are buying the judgement of the people who will build it, and judgement shows in the questions they ask you back.
How PluginZ answers these questions
For the record, and so you can hold us to it: our named work includes a hardened Azure environment for Sama Systems, a Saudi financial technology company, and a custom ERP built from scratch for Alfalak, both published with the clients’ approval. PluginZ Solutions is certified to ISO/IEC 27001:2022, verifiable on IAF CertSearch. We build bilingual by default, price fixed scope after a paid discovery sprint, and leave the code and data with you. We run our own platform, Ops360, in production in Arabic and English, and we integrate e-invoicing for both ZATCA and the UAE model. If a custom system is on your roadmap, we would rather scope it honestly than win it quickly.
Frequently asked questions
How much does custom software development cost in Saudi Arabia and the UAE?
A typical web or mobile product starts around USD 20,000 and a custom ERP is usually a phased programme starting from around USD 80,000, priced as fixed scope with milestone payments after a paid discovery sprint. The range is wide because scope, integrations and data migration drive the number more than the country does.
Should I choose a local Gulf software company or a regional one?
Choose on proof, security and process rather than the address on the letterhead. A regional engineering team working in your time zone, with named delivered work in the Gulf, an independent security certification and a legal entity you can contract with, usually offers better engineering depth for the budget than a small local shop, while a local presence for on-site work can be arranged when an engagement needs it.
Why does ISO 27001 matter when choosing a software vendor?
Your vendor will hold your customer data, financial records and internal processes. ISO/IEC 27001 certification means an external auditor has verified how the company controls access, handles incidents and protects client data, and re-audits it every year. It also shortens your own vendor security assessment, because the answer is a certificate number instead of a questionnaire.
Should the software company also host and support the system?
It is usually the better arrangement. One accountable team that designed the infrastructure, built the system and supports it in production avoids the finger-pointing between a developer, a hosting provider and a support desk. Make sure the contract still leaves you owning the code and data so you can change vendors if you need to.

