What to Prepare Before Hiring a Web Developer: A Project Brief Checklist

Most first messages I receive look like this: "Hi, how much for a website?" It's a fair question, but it's a bit like asking a builder how much a house costs. The honest answer is "it depends," and the things it depends on are things only you know.

The good news is that you don't need technical knowledge to answer them. You need to spend an hour thinking about your business and writing it down. This checklist walks you through what to prepare, why each item matters, and what a developer does with it.

1. The goal: what should the project achieve?

Start with the outcome, not the technology. "I need a website" is a solution; the goal is what that website should change for your business. Good goals are concrete:

• "Get more quote requests for our renovation services in Marrakech."
• "Let customers order online instead of messaging us on Instagram."
• "Stop managing orders in three different spreadsheets."
• "Give our clients a portal where they can download their documents."

The goal decides almost everything else. A site meant to generate calls needs clear service pages and visible contact buttons. A site meant to sell needs a catalogue, a cart and an order dashboard. If you can only answer one question before reaching out, answer this one.

2. The audience: who will use it?

Describe the people on the other side of the screen. Are they local customers searching on their phones, business buyers comparing suppliers on a laptop, or your own staff using an internal tool every day? Write down:

• Who they are and what they're trying to do when they arrive.
• Which devices they mostly use. For most public websites, assume phones first.
• Which languages they read. In Morocco this often means French, Arabic, English, or a mix, and each extra language adds work.

3. The scope: pages, screens and features

Next, list what the project includes. You don't need the right vocabulary, just a plain list.

For a website

List the pages you imagine: home, about, one page per service, contact, perhaps a blog or a gallery. One page per service is worth it, because each page can answer the questions customers ask about that specific service and can be found on Google for it. On the Le Point Travaux website, for example, electrical work, plumbing, plastering, tiling and painting each have their own page. See business website development for how I structure these.

For a dashboard or web app

Describe who logs in and what each type of user needs to do. For example: "Admins add products and see all orders. Confirmation agents see new orders and mark them confirmed or cancelled. Delivery staff only see orders assigned to them." This one paragraph tells a developer more than a long list of buzzwords. For ideas on which screens to include, read what a business admin dashboard should include.

Must-have versus nice-to-have

Split your list in two. Must-haves are what the first version can't launch without. Nice-to-haves can come later. This split is one of the most effective ways to keep a project within budget, because it gives you and the developer something to trade when time or money runs short.

4. The content you already have

Missing content is a frequent reason launches slip. The code can be ready while the site waits weeks for texts and photos. Take stock of:

• Logo and brand colours, ideally as vector files (SVG, Adobe Illustrator .ai or PDF).
• Texts for each page, even in rough form. A developer can help structure and tighten them, but you know your services best.
• Photos of your work, team or products. Real photos usually build more trust than stock images.
• Product data for a store: names, prices, variants and descriptions, preferably in a spreadsheet. (More on stores in e-commerce development.)

If you don't have content yet, say so. It's not a problem, but it changes the plan and possibly the quote.

5. Examples you like and dislike

Collect three to five links to sites or apps you like, and say why: "I like how clear the pricing is," "I like the big photos," "I like that I can book in two clicks." Dislikes are just as useful. Examples turn vague words like "modern" or "clean" into something a developer can see.

6. Existing systems and accounts

List what's already in place, because new work often has to connect to it:

• Your domain name and who it's registered with.
• Current hosting and any existing website.
• Tools the project must talk to: payment providers, delivery companies, a CRM, email marketing, messaging apps.
• Who has the passwords. Never send passwords by email in your first message; just note that the accounts exist.

7. Budget range and timeline

Many people hesitate to share a budget, fearing the quote will simply rise to meet it. In practice, a range helps a developer suggest the right scope. With a small budget, I'll propose a focused first version. With a larger one, I can include the nice-to-haves. Without any range, both sides waste time on proposals that don't fit.

For the timeline, separate a real deadline ("our shop opens on March 1") from a preference ("as soon as possible"). Real deadlines shape the plan; preferences don't.

A one-page brief template you can copy

Copy this into an email or document and fill it in. Short answers are fine.

What a good developer does with your brief

A brief starts the conversation; it doesn't end it. A developer who takes your project seriously should come back with questions, point out anything that's unclear or risky, and suggest where to simplify. From there you should receive a written scope listing what's included, a timeline with milestones, and a price. Once you have proposals in hand, these questions to ask a developer before you sign help you compare them.

You don't need a perfect brief. You need an honest one. Even half the answers above will make your first conversation with any developer faster, clearer and more useful.