What to prepare before building your company website

Why preparation matters

Most delays in a website project come from missing content and undecided questions, not from the code. The slow part is rarely the build. It is waiting for the services text, the logo file, the photos, or a decision on whether the site needs Arabic.

This is the checklist I would hand any company before we start. You do not need everything finished before the first call, but you should know which parts are ready and who owns the rest. Good preparation gives you a more accurate website design quote, a timeline that holds, and a site that says what your business actually does.

Decide what the site is for

Pick the one action you want a visitor to take: ask for a quote, book a visit, buy, call, or send a WhatsApp message. Write it in one sentence. The whole site is then designed to lead there: the main button on every page, the order of the sections, and what the contact form asks for.

On the LVMR Group website, the home page asks visitors to choose their need, such as offices, glazing or post-works cleaning, before they request a quote. On the Aevenda website, a visitor can start planning an event from the first screen with a date, a guest count and a location.

Secondary actions, such as downloading a company profile or applying for a job, are fine. Just rank them. Five buttons with equal weight usually means the visitor presses none.

Know who the site is for

The Midex website, for example, speaks to plant engineers and buyers in pharmaceutical, food and cosmetics plants, so its pages lead with engineering capabilities, products and case studies. Describe your own visitors the same way by answering these questions:

• Who are they: business owners, procurement teams, engineers, families, students?
• Where are they: one city, one country, the Gulf, Europe?
• Which language do they search and read in?
• Are they on a phone between meetings, or at a desk comparing suppliers?
• What do they already know about your field, and what needs explaining?
• What do they ask your sales team before they buy, and what makes them hesitate? Those questions often become sections on your pages.

Draft the page list (sitemap)

A sitemap at this stage is simply the list of pages and how they are grouped. Write it before asking for quotes, because the number of pages, and how different they are, is one of the biggest drivers of price and timeline.

Give each main service its own page instead of one long services page. It can answer that service's specific questions, and it gives Google a clear page to show for that search.

If you are replacing an old website, list its current pages too. Each old address should point to its new one with a permanent (301) redirect, so saved links and Google results do not end in an error page.

A typical company site looks like this. Mark what you need at launch and what can wait:

/                         Home
/about                    About the company
/services                 All services, briefly
/services/service-one     One page per main service
/services/service-two
/projects                 Work and case studies
/projects/project-name    One page per project (optional)
/blog                     Articles (optional, can come later)
/careers                  Jobs (optional)
/contact                  Form, WhatsApp, phone, map
/privacy                  Privacy policy
/terms                    Terms of use

Plan the content for every page

• The purpose of the page, in one sentence
• The headline a visitor sees first
• Three to five key points, in the order a visitor needs them
• Proof: photos, project examples, certificates, client names you may publish
• The action at the end of the page, such as a quote form or a WhatsApp button
• The person who writes it, and the date it is due

Then decide who writes the text: someone in your company who knows the work, a copywriter, or the developer's team. Either way, someone on your side must check the facts: services, certifications, coverage areas and hours.

Do not design around placeholder text; real headlines are longer or shorter, and those pages often get redone. And do not copy a competitor's text: it reads like everyone else, and copied pages rarely do well in search.

Also decide who updates the site after launch. If your team will add projects or articles, ask for an admin panel and a short handover. If the developer will, agree how changes are requested and billed.

Arabic, English or both

Arabic changes the layout, not just the words: the page reads right to left, menus and icons flip, and the text needs a font that supports Arabic well. Adding it after launch costs more than planning it from the start.

Decide which language comes first. For customers in Saudi Arabia and the UAE, Arabic and English together is a common choice. Selling to Europe may need the local language: the LVMR Group website is in French because its clients are in Île-de-France, and the Midex website runs in English, Arabic and German.

Decide who writes each language. Machine translation is rarely good enough for the pages that sell, so write each version for its reader, using the words that reader searches for. Plan the versions as one site, each page linked to its counterpart, so the developer can mark the pairs with hreflang tags for Google.

Brand assets: logo, colours and fonts

• The logo as a vector file (SVG, AI, EPS or PDF), not a screenshot or a small PNG
• Logo versions: full, icon only, and one for dark backgrounds
• A square icon for the browser tab and link previews
• Exact colour codes (HEX), not ‘the blue from our brochure’
• Font names, font files, and the licence for each
• Brand guidelines, if you have them

Fonts need special attention. A font bought for print or desktop use does not always cover use on a website, and some web licences forbid converting the files or hosting them where anyone can download them. Check the licence before the design is built around a font.

If your brand font has no Arabic letters, choose an Arabic font that matches its weight and feel; many on Google Fonts are free for web use under open licences. If you have no brand yet, say so early: a logo and basic identity can be part of the project, but they belong in the quote.

Real photos or stock photos

Real photos of your team, your work, your office or your products build more trust than any stock image. They show the visitor that the company exists.

If you do not have good photos, plan a short shoot before the design is final. Make a shot list: the team, the office or site, work in progress, finished projects, products on a plain background, and a few wide shots that can sit behind text. Ask for landscape and portrait versions, because phones crop images differently.

Stock photos are fine for backgrounds, not for anything that claims to be you, such as ‘our team’. Either way, keep a record of each image's source and licence, agree in writing that you can use a photographer's work on your site and social media, and ask permission from the people in the photos.

Send the original files, not images saved from WhatsApp, which compresses them.

Websites you like, and why

Collect three to five websites you like, from any industry, with one line each on what you like: the home page layout, how services are explained, the tone, the photography, or one feature. ‘I like it’ does not help a designer. ‘Their services page has a short FAQ under each service’ does.

Add one or two sites you dislike, and say why. List your main competitors too, so the developer knows what your customers compare you with. These are references for direction, not templates to copy.

Domain, email and the accounts you should own

• The domain name, registered under a company email address
• DNS settings, if managed elsewhere, such as Cloudflare
• Hosting, or the platform the site runs on
• Business email, such as Google Workspace or Microsoft 365
• Google Analytics and Google Search Console
• Google Business Profile, if customers visit an office or branch
• The code repository and the design files
• Any form, booking, CRM or newsletter tool the site uses

Register each one to your company under an address like [email protected], not a personal email. Add the developer as a user, not the owner, so access can be removed when the work ends.

The domain causes the most trouble. If a former employee or agency registered it under their own account, getting it back can take weeks. Check today who holds it and when it renews, and turn on auto-renew.

If you already have email on the domain, tell the developer before anything changes: moving the DNS without copying the email (MX) records will stop your email. Ask for SPF, DKIM and DMARC records too, so messages from the contact form do not land in spam.

For a new domain, keep it short and easy to spell. A .com works everywhere; country domains such as .eg, .sa or .ae look local but have their own registration rules. Finally, write into the contract that the code, design files and content are yours once the project is paid.

Legal pages: privacy policy and terms

If your site has a contact form, analytics or a newsletter, it collects personal data, so you need a privacy policy: what you collect, why, how long you keep it, and how people can ask you to delete it.

The EU has the GDPR, and Egypt, Saudi Arabia and the UAE each have their own personal data protection law. If you serve visitors in Europe, you also need their consent before setting non-essential cookies, such as most analytics and advertising cookies.

You need terms of use if you sell online, take bookings, or have conditions such as cancellations and refunds, and an online store also needs shipping and returns pages. Some countries and sectors require legal details on the site too, such as a commercial registration number.

I am a developer, not a lawyer. I build these pages and the cookie banner, but a lawyer who knows your business should write or review the text. Copying another company's privacy policy is a common mistake: it describes their data, not yours.

Contact channels and integrations

• WhatsApp: which number, and who replies
• Contact form: which fields, and where messages go (an inbox, a CRM, or both)
• Phone: a number visitors can tap to call, and the hours it is answered
• Email: a shared company address, not one person's inbox
• Location: address, map and Google Business Profile, if you have an office

Decide who answers each channel. A WhatsApp button nobody replies to is worse than no button. Keep forms short: a name, a phone number or email, and the request. Ask for more details in your reply.

For WhatsApp, the developer will use a click-to-chat link with your number in international format, optionally with a ready message naming the page the visitor came from. Use a company number on the WhatsApp Business app or Platform, not an employee's personal number.

Then list the tools the site must connect to: a CRM such as HubSpot or Zoho, a booking calendar, online payments, a newsletter tool or a careers form. For each, note who holds the account and what should happen when a visitor submits something. Every integration adds work, so mark which are needed at launch.

Analytics, Search Console and keywords per page

Set up measurement before launch so you have data from day one. Google Analytics shows visits and what visitors do. Google Search Console shows which searches show your site on Google, which pages are indexed, and any problems. Bing Webmaster Tools does the same for Bing and can import your sites from Search Console.

Track the actions that count as leads as events: form submissions and clicks on WhatsApp, phone and email. Then you see which pages bring enquiries, not just visits. Verify Search Console as a domain property through a DNS record, keep your company as the owner, and give the developer full access.

For keywords, give each important page one main phrase per language: the words a customer types when they need that service, not your internal names. Arabic wording also differs by country. A customer in Egypt may search for صيانة تكييف, while one in the Gulf types صيانة مكيفات, so each page should use the words of its market.

To find them, start with the questions your sales team hears and what Google suggests as you type. An old site's Search Console data already lists the searches that bring visitors. One main phrase per page is enough; repeating it does not help.

Deadlines, approvals and what launches first

Set the launch date and say why it matters: an exhibition, a product launch, a Ramadan campaign. Then work backwards: content and photos before design, design approval before the build, and a review on a test link before launch.

Name one person who approves. Others can give feedback, but one person collects it into one list and decides. Projects slow down when people send contradicting comments, or when a senior manager first sees the site the day before launch. Agree on the number of design revision rounds, and keep feedback specific: which page, which section, what to change, and why.

Split the features into must have at launch and can wait. A site that launches on time with the core pages and adds a blog or client area later usually beats one that waits for everything. Share your budget range and which items are flexible, so the proposal can be shaped around it.

The brief to send to a developer

Put your answers into one short document. Send the same brief to every developer or agency you talk to, so the quotes describe the same project and you can compare them fairly. Ask each quote to list what is included and what is not.

Here is the template I would want to receive. Copy it and fill in what you know; ‘not decided yet’ is a valid answer for any line:

Company: name, what you do, the countries or cities you serve
Goal: the one action you want visitors to take
Audience: who visits, from where, in which language
Pages: home, about, services (list them), projects, contact, others
Languages: Arabic, English, other; which one is primary
Content: ready / partly ready / need help writing
Photos: our own / need a shoot / stock
Brand: logo files, colours, fonts (attached or linked)
Sites we like: three links, one line each on why
Competitors: names and websites
Contact channels: form, WhatsApp, phone, email, map
Integrations: CRM, booking, payments, newsletter, other
Domain and email: current domain, who holds the account
Updates after launch: our team / the developer
Must have at launch:
Can wait for phase two:
Deadline: the date, and why that date
Decision maker: name and role
Budget range: optional, but it helps shape the proposal

What to do next

Start with the three decisions everything depends on: the one action, the languages and the page list. Then check who holds your domain and email; it is the item most likely to surprise you.

Next, give each content item an owner and a date, put the brand files in one folder, and decide whether you need a photo shoot. Fill in the brief, gaps included, and send it. If you would like me to look at it, send it through the contact page and I will tell you what is missing and what the project needs to be quoted accurately.

Common questions

What should I prepare before hiring a web developer?

Prepare the goal of the site and the main action you want from visitors, the page list, the content or who will write it, your logo and brand files, the languages, your domain and email details, and a deadline. Put them in a short brief and send the same one to every developer, so the quotes can be compared.

How long does it take to build a company website?

It depends on the number of pages, the languages, whether the design is custom, and which integrations are needed. In practice, the timeline depends as much on how fast content and approvals arrive as on the build itself. Ask the developer for a schedule that shows the dates they need your inputs.

Does a small business website need a privacy policy?

If the site collects any personal data through a contact form, analytics or a newsletter, then in most markets the answer is yes. The EU, Egypt, Saudi Arabia and the UAE all have personal data protection laws. Have a lawyer write or review the policy rather than copying another company's.

Who should own the domain name and hosting account?

Your company, registered under a company email address rather than a personal one. The developer gets user access for what they need, and that access is removed when the work ends. That way you do not lose the domain when a staff member or an agency moves on.

Should my company website be in Arabic and English?

If your customers are in Egypt or the Gulf, Arabic is usually expected, and English helps when you sell to companies or international visitors. Decide before design starts, because Arabic changes the layout. Write each version for its reader instead of translating word for word.

Can I use stock photos on my business website?

Yes, for backgrounds and general ideas, as long as you have a licence for each image. Pages about your team or your projects need real photos, because visitors recognise stock images. Keep a record of where every image came from and its licence.