Blog Overview
Most software proposals in Saudi Arabia look the same. These twelve questions, and the evidence to request behind each answer, separate the team that builds a system still working a year from now from the one selling a slide deck.
Most software companies in Saudi Arabia answer a request for proposal with the same sentences: modern stack, local understanding, integrated team. The real differences appear after the contract is signed: who owns the code, who tests the system, and who answers when it breaks on launch day.
This guide does not rank companies or compare prices. It gives you twelve questions to use in any meeting, and the evidence to ask for behind each answer. The same questions work for a client portal, an invoicing system, or a government site.
Why the proposals look the same
Because the proposal is written before anyone understands the problem. The template is always the same: scope, phases, price, duration. The template cannot reveal what happens when the data differs from the assumption, when the auditor asks for an invoice change, or when an Arabic user abandons a form because the fields run in the wrong direction.
The real difference sits in three places: how discovery is run, how the system is tested, and how it is handed over. That is the space that changes the outcome a year from now, and it is also the space you can inspect before you sign.
First: four questions about scope
“Show me what you will not build.” What did you exclude, and why? A good answer names deliberately deferred features, not a vague list. Anyone who says “anything is possible” has not finished scoping.
“Who wrote this scope, and when did they last talk to a real user?” If the scope was copied from an earlier proposal or generated end to end, you will pay for the missing discovery later.
“What decision do you need from me, and when?” Projects stall when the vendor waits for a decision you did not know was yours. The plan should name each decision and its owner.
“How will you know the first release succeeded?” “Screens delivered” is not a success criterion. A good one: 80% of client requests are completed without an email or a phone call.
Second: four questions about engineering and security
“Where is client data stored, and who can reach it?” Ask for a data map, not a confidentiality promise. In Saudi Arabia, storage location and transfer paths are also a regulatory question, especially as PDPL moves toward clearer rules on storage and transfers outside the Kingdom.
“How are permissions checked on the server, not in the interface?” Every state-changing action needs a server-side check. Test it yourself: open two accounts and try to reach a document that one of them does not own.
“What happens when an integration fails?” A connection to ZATCA, Nafath, or an ERP is not enough. Ask about retries, queues, alerts, and logs. A good system fails quietly and retries; a bad one loses an invoice.
“Show me a test report, not a screen.” Ask for results from a real device, in Arabic and English, including failure cases. A beautiful screen does not prove the form works.
Third: four questions about delivery and ownership
“Who will work on this after we sign, and will they stay?” Names matter more than logos. Ask for each person’s time commitment, and who replaces them if they leave.
“What do I receive on handover day?” The repository, the database, the deployment configuration, the documentation, and the dependency list. If any of those stays “company property”, you are renting a product, not owning a system.
“What happens after 90 days?” Who fixes the defect? What is the service-level agreement? What does leaving cost? Ask about care before launch, not after.
“Can I run this without you?” The real ownership test: can your team, or another team, deploy the next release from the repository without calling you?
How to verify the answers
Do not settle for words. Every answer has evidence you can request in the meeting or the next day. The table below maps each promise to the proof to ask for.
| Promise | Evidence to request | How to check it |
|---|---|---|
| Clear scope | A document stating what will and will not be built, with acceptance criteria | A 60–90 minute discovery session, then the document within a week |
| Real security | Permission model, threat review, audit log | A sample review or penetration-test report |
| Quality | Test plan and acceptance cases | An actual test report, not a list of tools |
| Ownership | A handover clause for code and data | A staging repository, or a contract that names the assets |
| Reference | A client you can call | One reference call beats five written testimonials |
| Support | A written SLA | Response numbers, not “around the clock” promises |
From reading to shipping
Want this built, not just explained?
Bring us the problem behind the article. We will tell you what it takes, what it costs, and whether we are the right team.
Warning signs worth walking away from
- A fixed price before any discovery session.
- “We will add security in phase two.”
- No named delivery team in the proposal.
- The code stays company property, and hosting must stay with them.
- A promise to integrate ZATCA or Nafath “in a week” with no mention of registration or testing.
- No test environment, or no test report.
- Arabic review “added later”.
- A contract that says nothing about what happens on termination.
The real price is not the contract price
The contract is only the first payment. The full cost includes the build, integrations, hosting, care, and internal migration. A vendor that is 20% cheaper can cost more after a year if you have to rebuild an integration or move the data.
| Line | When you pay | What it usually covers |
|---|---|---|
| Build | Once | Discovery, design, development, testing, launch |
| Integrations | Once + maintenance | ZATCA, Nafath, ERP, Mada, single sign-on |
| Hosting | Monthly | Server, database, backups, monitoring |
| Care | Monthly | Fixes, security patches, small improvements |
| Migration | On change | Export, re-import, and verification of data |
That is why Rasad publishes its bands instead of hiding them: you can compare the shape before the call. See the pricing page for the difference between a first release, a full build, and care.
A 100-point scorecard
Do not let price decide alone. These weights reflect what determines the system’s success a year from now, not what looks good in the proposal.
| Criterion | Weight | The question it answers |
|---|---|---|
| Scope clarity | 20 | Do we know what will and will not be built? |
| Security and permissions | 20 | Is the data protected on the server, not only in the UI? |
| Testing quality | 15 | Have we seen a report of real cases? |
| Ownership and handover | 15 | Can we run it without them? |
| Integrations | 10 | Do they understand integration failure before success? |
| Post-launch support | 10 | Who answers the first incident? |
| Reference | 5 | Have we spoken to a real client? |
| Price within budget | 5 | Is the scope worth the number? |
A decision in three minutes
Ask for a two-page scope document, not a 40-page proposal.
Test permissions yourself in a staging environment.
Call one reference and ask about launch day, not the outcome.
Read the ownership and exit clauses before the price.
Calculate three-year cost, not one-year cost.
Sources and further reading
- ZATCA: Wave 25 e-invoicing criteria — a live example of a regulatory requirement that changes the scope of any finance system.
- PDPL Implementing Regulation — the official reference for processing and breach obligations.
- Rasad’s published price bands — the numbers we work from, published before the call.
- Custom portal vs off-the-shelf platform — when a custom build is the right decision.
This article is not legal advice. It is a list of questions that helps you buy engineering work with more clarity.
