Website Requirements Brief: Write One Before Getting Quotes

Introduction

• You ask three companies to quote for a website or app and get three very different numbers. Usually none of them is unreasonable; each company simply understood your request differently.
• A requirements brief is a short document explaining what you want built and why. It is not a technical specification, and you do not need programming knowledge to write one.
• This guide explains why you need a brief, what sections to include, gives you a fill-in template, and lists the gaps that cause scope creep and higher costs later.
• It suits business owners in Oman, the Gulf, Yemen and the wider Arab region, whether the project is a company website, an online store or an app.

Why a brief makes quotes comparable

• Same question, comparable answers: when every company reads the same document, quotes differ in price and approach, not in what they think you asked for.
• Fewer questions, less time: most first-meeting questions are already answered in the brief.
• A reference in disputes: if you later ask for something not in the brief, it is clearly an addition, and the reverse is also true.
• Clearer thinking: writing requirements reveals decisions you have not made yet, such as languages or payment methods.
• More accurate estimates: serious companies prefer a clear brief because it reduces risk in estimating time and cost.

Sections of a good brief

1. Project goal

• One or two sentences: what must the site or app achieve?
• Examples: "receive booking requests via WhatsApp", "sell products directly with online payment", "present our services to companies and collect quote requests".
• State how you will know it worked: number of enquiries, fewer repeat phone calls, an easier workflow for your team.

2. Audience

• Who will use it? Individuals or businesses? In which country?
• On which device, mostly? In this region most people browse on a phone, which shapes the design.
• Will your internal team use it too, for example a dashboard to manage orders?

3. Pages and features list

• Name the pages: home, about, services, one page per service, FAQ, contact.
• Describe features in plain words: "quote request form", "book an appointment by date and time", "cart and checkout", "customer account showing past orders".
• Split features into needed for launch and can wait. This alone helps control the budget.
• For a store, give the approximate number of products and categories, and whether there are options such as size and colour.

4. Languages

• Arabic only, or Arabic and English? Do you need both on launch day?
• Who translates? Good translation is real work and takes time.

5. Content owner

• Who writes the copy, and who supplies photos, logo and video?
• Is the content ready, or does it need writing from scratch?
• If the agency is responsible, say so clearly, as it is a separate cost item.

6. Integrations

• Payment gateway: which gateway is available for your business in your country? Do you already have a merchant account?
• WhatsApp: a simple chat button, or automated messages through the official WhatsApp API?
• Other systems: a CRM, accounting software, shipping provider or booking system you already use.
• If your customers are in more than one Gulf or Arab country, list the currencies and shipping methods each one needs.
• Name each system if you know it. Every integration is estimated based on the other system's documentation and complexity, and is often a separate piece of work. See our API integrations service for what this involves.

7. Examples you like

• Share links to sites or apps you like and say exactly what you like: the colours, the page layout, the booking flow.
• Add examples you dislike too. It saves several revision rounds.

8. Budget range

• Give a rough range. Hiding your budget does not make the quote cheaper; it makes companies propose solutions that may not fit.
• With a range, a company can say: "this is possible now, and this can move to phase two".

9. Deadline

• When do you need to launch, and why? A deadline tied to a season or an opening is different from a flexible one.
• List any fixed dates that cannot move, such as a booked ad campaign.

10. Existing technical details

• Do you own a domain? In whose name? Do you have hosting already?
• Is there an old website? Do you want its content or URLs carried over?
• Who will run the site after launch, and does your team need training?

A fill-in brief template

Copy this table and complete it before contacting any company:

Common gaps that cause scope creep

Scope creep means a project grows during delivery with requests that were never agreed, so it runs late and costs more. Most of it comes from gaps in the brief:

• "An admin panel" with no detail: what exactly will you edit? Text only, or products, prices, orders and reports?
• User accounts: do customers need accounts? Do your staff need different permission levels?
• A late second language: adding English after launch is harder than planning for it from the start.
• Unmentioned integrations: asking to connect accounting or shipping after development starts changes the whole estimate.
• Uncounted content: thirty service pages with no copy ready means weeks of extra work.
• Notifications: emails or WhatsApp messages to customers and admins on each order must be listed explicitly.
• Data migration: moving products, customers and past orders from an old system is separate work.
• No clear decision maker: when one person approves and another objects, revision rounds multiply.
• App versus website: "we want an app" can mean a store-listed app or a site that works well on mobile. Say which you mean.

Common mistakes when writing a brief

• Describing a solution instead of the problem: "we want an app like that one" is less useful than "customers call to confirm every booking and we want fewer of those calls". Explain the problem, let the company propose a solution, then discuss it.
• A wish list with no priorities: twenty features of equal weight mean a high quote and a long timeline. Mark only what launch truly needs.
• Vague words: "modern design" and "easy to use" mean different things to different people. Attach examples instead.
• Hiding constraints: if you have an existing system that cannot change, a required payment gateway, or regulatory requirements in your sector, say so from the start.
• Forgetting life after launch: who will update content? Does your team need training on the admin panel? Do you want a monthly maintenance plan? These affect the quote.
• A long, unordered brief: ten pages of scattered notes are harder to use than two pages organised by the sections above.

How to send the brief and read the replies

• Send the same brief to every company and ask each proposal to state what is included and what is out of scope.
• Ask for the price broken into items and stages, not one figure.
• Ask each company to write down the assumptions behind its quote, such as page count, product count or revision rounds.
• If a company suggests postponing or dropping a feature, ask why. It may save cost without hurting the goal.
• If a company asks you precise questions about the brief, that is a good sign it actually read it.
• To understand the order of work after you approve a proposal, see website creation steps.
• If something changes, update the brief and send the new version to everyone.

Summary

• A clear brief makes quotes comparable, cuts down questions and protects you from scope creep.
• Its core sections: goal, audience, pages and features, languages, content owner, integrations, examples, budget and deadline.
• Split features into launch and later, name every integration, and decide who has the final say.
• If you would like a proposal based on your brief, send it to us through our website design and development service, starting from 100 OMR, and we will come back with our questions and an itemised proposal.