Insights · Company websites
How to briefa web developerfor your website.
A good brief gets you quotes you can compare, fewer surprises during the project, and a website that does a job for the business.
You don't need a technical specification. You need to answer eight questions clearly, and then ask every developer for the same things in their proposal.
1. What should the website do for the business?
Bring in enquiries for a product line, get you onto tender shortlists, help recruitment, reassure investors — pick the two that matter most, and say how you will know it is working (for example, qualified enquiries per month).
2. Who is it for?
Clients, procurement committees, partners, candidates. Note what each group needs to find in the first minute: what you do, which projects you have delivered, certifications, and who to contact.
3. Which pages, and who writes them?
List the pages you expect, and decide early who provides the text, project information, photos and documents. Content is the most common reason website projects run late. Decide now whether you need Arabic and English, because it affects structure and design, not just translation.
4. Where do enquiries go?
For each form, who receives it, who replies, and where it is recorded. If enquiries currently arrive by phone, WhatsApp and email with no record, say so — it changes what you should build.
5. What does it need to connect to?
A CRM, an ERP, an email platform, a booking tool. Ask whether each one has an API or an export before anyone promises an integration.
6. Who decides, and how?
Name the person who approves the work and how many review rounds you expect. Projects slow down when approvals arrive late or from people who were not in the brief.
7. Are there fixed dates?
A launch, an exhibition or a tender deadline. Say which date is fixed and which is a preference.
8. What budget range are you working with?
A range lets developers propose the right scope instead of guessing. Without one, quotes are hard to compare.
What to ask for in every proposal
- A list of pages and features that are included — and what is not.
- Who owns the code, the hosting account and the domain at the end of the project.
- A timeline that shows which steps depend on you.
- How many review rounds are included, and how changes are priced.
- What happens after launch: fixes, updates, backups and support.
- The payment schedule.
If two proposals answer these the same way, you can compare them on price and on the work each team has already delivered.
Want a second pair of eyes? Send us your brief, or the questions above answered roughly, and we'll tell you what we'd build first.