Software, App and Website RFP Template (Free Word Download): How to Write an RFP in the UAE
A free RFP template in Word, in English and Arabic, for an app, website or software project in the UAE: 17 sections, what each is for, and mistakes to avoid.
An RFP (request for proposal) for an app, website or software project gives every vendor the same facts, so their proposals come back in the same shape and you can compare them line by line. Our template is a free Word file, in English and in Arabic, with 17 sections to fill in, a short note on what each is for, and a scoring table for the replies. No sign-up.
Download the RFP template (Word) Arabic version, right to left (Word)
How do you write an RFP for an app, website or software project?
Quick answer: Start with the business problem and how you will measure success. Then list the users, the must-have features and the systems the software connects to. Add what UAE projects need: Arabic and right to left, UAE PASS, payment gateways and where the data must be stored. Give your dates, say who owns the code and the accounts, tell vendors exactly what to send, and agree how you will score the replies before they arrive.
Already comparing vendors? Send us the proposal you received → or send us your RFP →
What a vague RFP costs you
Send five vendors a two-line email and you get five proposals for five different products. One leaves out the admin panel. One prices English only and adds Arabic later as a change request. One looks cheapest because it assumed your payment gateway account and your copy were ready. The lowest figure is often the one with the most missing, and you find out after you sign. A clear RFP doesn’t make the work smaller; it makes the proposals comparable, which is how you avoid paying twice for the same product.
What’s in the template: the 17 sections
Each section has an italic note for you, blank boxes or a table to fill in, and grey example rows to overwrite.
| # | Section | What it’s for | What goes wrong without it |
|---|---|---|---|
| 1 | About your company | Who you are, what you sell, who your customers are | Vendors design for a business they don’t understand |
| 2 | Goals and success measures | The problem today, and how you’ll judge the result | Proposals sell features, not outcomes |
| 3 | Users and roles | Every kind of user, staff and admins included | The admin side is missed, then priced as an extra |
| 4 | Scope: must-have, nice-to-have, later | Every feature, sorted by priority | Each vendor guesses a different first release |
| 5 | Platforms | iOS, Android, web, admin panel | One vendor quotes one app, another quotes three |
| 6 | Languages and right to left | Arabic and English, digits, dates | Arabic arrives late, as a change request |
| 7 | Integrations | UAE PASS, payments, ERP, CRM, WhatsApp | Estimates miss the hardest part of the work |
| 8 | Content and design assets | What you have, and what the vendor creates | Launch waits for copy and photos |
| 9 | Data and hosting | What data you hold, and where it must live | A late surprise from compliance |
| 10 | Security | Sign-in, permissions, testing, standards | Every vendor says “yes”, and none says how |
| 11 | Timeline | Your dates, and which ones can move | Plans that ignore your launch event |
| 12 | Budget | A range, if you choose to share one | Proposals sized for a budget they imagined |
| 13 | Ownership: code, accounts and IP | Whose name the repository and store accounts are in | A hard exit if you change vendor |
| 14 | Support after launch | Warranty, response times, yearly iOS and Android updates | A launch with no one on call |
| 15 | What each vendor should send | One proposal format for everyone | Five formats you can’t compare |
| 16 | How we will compare proposals | Criteria, weights and a score from 1 to 5 | The decision goes to the smoothest pitch |
| 17 | Submission details | One contact, one deadline, one format | Vendors work from different information |
The Word file adds a cover page, tick boxes, and a short checklist to run before you send. Delete the notes and the grey examples before it goes out.
Holding proposals already? Send us the one you received, with anything confidential removed. We reply with the questions to ask that vendor and what we would change before you sign. Send us the proposal →
Not ready for that? Ask for our company profile and we’ll send it to you.
Five things UAE and GCC projects can’t leave out
Generic templates written for other markets skip these, and they are where Gulf projects most often change size after the contract.
- Arabic and right to left. Say which languages launch, which is the default, who writes the Arabic copy, whether users type Arabic names and addresses, and which digits and calendar you show. A right-to-left layout mirrors screens, icons and forms, so it is designed and tested from the first screen, not translated at the end. Our guide to Arabic localization and right-to-left design shows what to check.
- UAE PASS. If customers or staff will sign in or sign documents with UAE PASS, say so in the RFP. Connecting to it has its own onboarding and testing steps, so the vendor has to plan for them.
- Payment gateways and wallets. Name your gateway if you already have one, and say whether you need Apple Pay and Google Pay. If you don’t have a merchant account yet, say that too: someone has to open it.
- WhatsApp, ERP and CRM. Gulf customers often expect order updates on WhatsApp, and back-office data usually lives in an ERP or a CRM. List each system, its provider and who holds the account.
- Where the data lives. UAE federal and free-zone data protection rules, and sector rules in areas such as health, finance and government work, can decide where personal data is stored. Ask your legal or compliance adviser what applies, and write the answer in the RFP instead of leaving each vendor to guess.
Ask each vendor, too, for the legal entity that would sign, its trade licence and its Tax Registration Number (TRN), so VAT invoices work from the first payment.
How to write the scope so every vendor prices the same thing
- Start each feature with a user. “A customer can book a slot and pay by card” prices better than “booking module”.
- Keep the must-have list short. Anything the first release can launch without goes to nice-to-have or later. Listing the later features still helps: the design leaves room for them.
- Count the roles. Each role usually needs its own screens and permissions, and the admin panel is a product in its own right.
- Write what is out of scope. One line here saves an argument later.
- Attach what you have. A screenshot of today’s spreadsheet or a sketch of the process often explains more than a page of text.
- Write “Not sure” when you are. Don’t invent requirements to look complete. A good vendor will ask, and their questions tell you how they think.
For a mobile app, the app brief builder in our app cost guide turns a few answers into a one-page feature list you can paste into section 4.
How to compare the proposals you get back
Agree the weights before the first proposal arrives, so the decision isn’t shaped by the pitch you happened to like. Section 16 of the template has the table: score each criterion from 1 to 5, multiply by its weight, add up and divide by 5 for a total out of 100. Have two people score separately.
While you read, look for these signs:
| What you see in a proposal | What it usually means |
|---|---|
| No questions asked before the price | The vendor priced its own assumptions, not your project |
| The team is “to be assigned” | You don’t know who will build it |
| One price, with no phases or assumptions | Change requests will fill the gaps later |
| Arabic mentioned only as “translation” | Right to left wasn’t planned |
| Code or store accounts in the vendor’s name | Leaving that vendor will be hard |
| No live work you can open | Nothing you can check |
The proposal is half the decision; the firm behind it is the other half. Our scorecard for choosing a software development company in Dubai covers who builds, where they sit and which references to call. Our side-by-side look at mobile app development companies in the UAE helps you build an app shortlist, and for a website, our guide to website design cost in Dubai lists the questions to ask each quote.
What this means for you: a proposal that looks cheap but leaves out the admin panel, Arabic or support after launch is not cheap. Score what each one includes, not the total alone.
Common RFP mistakes, and what to do instead
- A feature list with no goal. Vendors can’t suggest a simpler route to a result they don’t know. Write the problem and the measure first (sections 1 and 2).
- Copying a long government tender for a small project. Public tender booklets suit public procurement. For a first app or website they bury what matters; keep the legal terms for the contract stage.
- Fixing the date, the scope and the budget all at once. Something has to give. Say which one can move (section 11).
- Giving no budget signal at all. Vendors then size their proposals for a budget they imagine. If you won’t share a range, say how the budget is approved.
- Different answers for different vendors. Share every question and its answer with all of them, or the proposals stop being comparable.
- Asking for a fixed price before the product is clear. If you are still deciding what to build, ask for a discovery phase first. Our guide to software product discovery in Dubai covers what you leave with.
- Leaving ownership for the handover. Ask for the code repository, store, domain and cloud accounts in your company’s name from day one (section 13).
RFP, brief or discovery: which one do you need?
| Your situation | What to send |
|---|---|
| You know what you need, and you’re comparing three or more vendors | This RFP |
| You have one or two vendors in mind and a clear idea | A short brief: goals, users, must-haves and dates |
| You’re still deciding what to build first | A request for discovery, then its output as your RFP |
| You already hold proposals that don’t line up | Score them with section 16, or send them to us for a second opinion |
Where Flojics fits
We build mobile apps, company websites and web platforms and portals in Arabic and English. When your RFP reaches us, we read it, send our questions, and reply with a written proposal in the format you asked for: the team, the phases, what each phase delivers, and our assumptions in writing. Testing is done by an independent QA role, separate from the developers, and our core team are native Arabic speakers, so the right-to-left screens are checked by people who read them.
Qargo is a car rental and ride-hailing platform we built for Qatar. Talk to the team that built it: book a meeting. Abdulhameed Aljasmi Advocates & Legal Consultants is a law firm whose multilingual website we designed. Talk to the team that built it: book a meeting.
Send us your RFP
Since 2014 we have worked with more than 100 clients across the UAE, Saudi Arabia, Qatar, Kuwait, the USA and Canada. Our headquarters is at Dubai Digital Park, and our core team works from Egypt.
Download the RFP template (Word) Arabic version, right to left (Word)
Send us your RFP → Fill in the template, or send what you have so far, and we reply with a written proposal. Already comparing vendors? Send us the proposal you received → We reply with the questions to ask and what we would change before you sign. We reply by email first and set up a call only if you want one. Asking commits you to nothing, and we sign an NDA first if you ask.
Frequently asked questions
What is an RFP in software development?
A request for proposal: one document that gives every vendor the same goals, users, scope, platforms, integrations and dates, and says how you will judge the replies. The proposals then come back in the same shape, so you can compare them.
What should an app or website RFP include?
Your company, goals and success measures, users and roles, the scope split into must-have, nice-to-have and later, platforms, languages, integrations, content, data and hosting, security, timeline, budget, ownership, support after launch, what each vendor should send, how you will score the replies, and the submission details. For the UAE, add Arabic and right to left, UAE PASS, payment gateways and where the data must be stored.
Should I put my budget in an RFP?
It is optional. A range lets vendors propose the right scope instead of guessing, and makes the proposals easier to compare. If you'd rather not share it, say how the budget will be approved.
How do I compare the proposals I get back?
Agree the criteria and their weights before any proposal arrives. Score each criterion from 1 to 5, multiply by its weight, add up and divide by 5 for a total out of 100. Have two people score separately, and score what each proposal includes, not only its total.
Do I need an RFP, a brief or a discovery phase?
Use an RFP when you know what you need and are comparing three or more vendors. A short brief is enough for one or two vendors and a clear idea. If you are still deciding what to build first, ask for discovery and use what it produces as your RFP.
Is the template free, and is there an Arabic version?
Yes. Both Word files download with no sign-up: one in English, and one in Arabic laid out right to left, where the RFP is called كراسة الشروط والمواصفات. Edit them as you like.
