Software RFP in Qatar: how to write one vendors can price

A software RFP in Qatar should give vendors enough detail to price the same project: the problem you are solving, who the users are, which systems it must connect to, the Arabic and English requirements, payments in QAR, data protection duties and how you will judge proposals. This guide gives a structure you can copy and explains which details matter most and which to leave open.

What is a software RFP, and when do you need one?

A request for proposal is a document that describes your project and asks vendors to respond with an approach, a plan and a price. You need one when the project is large enough that a wrong choice is expensive, or when you must compare several vendors on the same basis.

For a small website or a short fix, a one-page brief is enough. For a custom system, a customer portal, a mobile app or a replacement for an old platform, a written RFP saves time on both sides. It also forces your own team to agree on priorities before anyone starts building.

What should the RFP include?

Keep it short enough to read in one sitting and specific enough to price. This structure works for most projects:

• Background: who you are, what you do and why this project matters now
• Goals: the business outcomes you want, in plain language
• Users and roles: who will use the system, how many, and on which devices
• Current situation: the systems, spreadsheets and paper processes in use today
• Scope: the main processes the system must support, listed by priority
• Integrations: every system it must exchange data with, and whether an API exists
• Non-functional needs: languages, performance, security, hosting and availability
• Data: what must be migrated, from where and in what condition
• Constraints: budget range if you can share it, deadlines and fixed dates
• Response format: what vendors must include and how proposals will be scored
• Timeline: deadline for questions, submission date and decision date

How detailed should the requirements be?

Describe what users need to do and why, not how the screens should look. Vendors price risk, so vague requirements lead to padded quotes or low quotes followed by change requests.

Write requirements as short user stories, such as: as a branch manager, I approve purchase requests above my limit from my phone. Mark each as must have, should have or could have. Avoid specifying technology unless you have a real reason, such as an existing platform your IT team supports. Include examples of real documents, reports and edge cases. A sample invoice or a messy spreadsheet often explains more than a page of text.

Which Qatar-specific requirements belong in the RFP?

State the local requirements explicitly, because vendors will otherwise price them differently or miss them. Include these where they apply:

• English and Arabic, with full right-to-left layouts, and who will write the Arabic content
• Currency in QAR, and any other currencies you trade in
• Payments through QPay for NAPS debit cards, Visa and Mastercard, and Apple Pay
• Invoicing that can switch on a tax rate later, as Qatar has not implemented VAT at the time of writing
• Readiness for e-invoicing, since the Council of Ministers approved a draft e-invoicing law in May 2026
• Handling of personal data under Qatar's Personal Data Privacy Protection Law, Law No. 13 of 2016
• Hosting location, especially if contracts or sector rules require data in Qatar
• Support hours that match a Sunday to Thursday working week and Ramadan hours
• Ownership of code, cloud accounts and app store accounts by your company

Tax and data protection rules change, so ask your adviser to confirm current requirements before the RFP goes out. Our Qatar page summarises how we handle these points in projects.

What should vendors include in their response?

Ask for the same sections from every vendor, so you can compare like with like:

• Their understanding of the problem, in their own words
• Proposed approach, phases and what is in the first release
• Team roles, including a named lead and who you will speak to each week
• How they run the project: workshops, sprint length, demos and reporting
• Testing approach and how acceptance will work
• Assumptions and exclusions, written clearly
• Pricing structure, by phase, with running costs listed separately
• Support and maintenance terms after launch
• Examples of similar systems or a demo of relevant work

Assumptions and exclusions are where proposals really differ. Read them first.

How should you compare proposals?

Score proposals against criteria you set before reading them, and weight understanding and approach as heavily as price. The cheapest proposal is often the one that understood the least.

Decide which pricing model suits your project. A fixed price works when the scope is clear and stable, but it shifts risk to the vendor, which raises the price, and it makes changes formal. Time and materials suits projects where you expect to learn as you go, but needs closer control. A common middle ground is a fixed-price discovery phase followed by priced phases. The main cost drivers are the number of user roles, integrations, languages, data migration and how much support you need.

For example, a trading company in Qatar replacing spreadsheets with an order and stock system might shortlist three vendors, invite each to a call to walk through the RFP, and then score their written responses. A vendor that asks hard questions about stock adjustments and returns is showing that it has read the requirements properly.

Which RFP mistakes should you avoid?

Most weak RFPs fail in predictable ways. Check your draft against this list before you send it:

• Copying a feature list from another product instead of describing your own processes
• Leaving out integrations or data migration, which are often the hardest parts
• Asking for a fixed price on a scope that is still changing
• Giving vendors too little time to ask questions or respond properly
• Not naming who in your company decides, and who signs off each phase
• Scoring on price alone, or deciding the weighting after reading the proposals
• Forgetting running costs: hosting, licences, support and future changes

Answer vendor questions in writing and share every answer with all vendors. It keeps the process fair and often reveals gaps in the RFP itself that are worth fixing before anyone prices the work.

What happens after you choose a vendor?

The RFP becomes the starting point for discovery, not the final specification. This is how we run a project after selection.

Discovery is done in video-call workshops with your users, turning the RFP into a written scope with priorities and acceptance criteria. A named lead engineer owns delivery. Work runs in two-week sprints, with a demo of working software every sprint, so you can see progress rather than read about it. Our working hours overlap your full working day, Sunday to Thursday. Releases are phased, each tested by our QA team and then by your users, and at handover the code and cloud accounts are registered to your company. Our custom software development and startup and business consulting services cover both the build and help with writing the brief.

Frequently asked questions

Should we share our budget in the RFP?

A range helps. It lets vendors propose a realistic scope for what you can spend, instead of guessing and pricing very different solutions.

How many vendors should we invite?

Enough to compare, but few enough to read every response properly. A short list of serious vendors usually beats a long list of rushed responses.

Can a vendor help write the RFP?

A vendor can run a paid discovery to clarify requirements. If you plan a competitive process, share the resulting document with every vendor on equal terms.

If you are preparing an RFP and want a second view on scope or structure, talk to us.