What to Prepare Before Briefing a Web Developer

Most website projects that go wrong do not fail during development. They fail earlier, in the gap between what the business had in mind and what the developer understood from a short email or a rushed call. A vague brief produces a vague quote, and a vague quote tends to grow once the real requirements surface halfway through the build.

You do not need technical knowledge to write a good brief. You need to have thought through a handful of business questions and gathered some practical details. This guide walks through what to prepare, why each item matters, and ends with a checklist you can work through before you contact anyone.

Start with what the website needs to achieve

"We need a new website" is a starting point, not a goal. Before anything else, write down what the site should do for the business. Common goals include generating enquiries for a service, selling products online, taking bookings, recruiting staff, answering routine questions so your team spends less time on the phone, or giving credibility to a business that people already hear about through referrals.

Most sites serve more than one goal, so rank them. A developer will make different recommendations for a site whose main job is lead generation than for one whose main job is to support existing customers. If you can describe how you will judge success a year from now, such as more quote requests, fewer support calls, or online orders replacing phone orders, even better.

Describe who the site is for

Describe your main audiences in plain terms. Who are they, what do they already know about you, and what are they trying to find out when they arrive? A school website, for example, serves prospective parents, current parents, students, and job applicants, and each group wants different things. A local plumbing business might serve homeowners with an emergency and property managers looking for a regular contractor.

Note anything practical about how people will use the site. Are most of your customers on phones? Do they need content in more than one language? Are some of them less comfortable with technology? These details shape design decisions.

Sketch the pages and the content behind them

A rough sitemap does not need to be final. A simple list of pages, grouped into sections, helps a developer estimate scope far more accurately than "about ten pages." For each page, add a line about what it is for. If you have many similar pages, such as individual services, locations, or product categories, say roughly how many.

Then answer the question that delays more projects than any technical issue: who is writing and supplying the content? If you plan to write it yourself, decide who on your team owns it and when it will be ready. If you need help with copy, photography, or product descriptions, say so upfront so it can be included in the plan. Content arriving late is one of the most common reasons launches slip. If writing is a gap, consider professional content writing as part of the project rather than an afterthought. Our guide on writing service pages that answer real questions covers what good page copy needs to include.

Collect examples, and explain why you like them

Links to websites you like are useful, but only when they come with reasons. "I like this site" tells a designer very little. "I like how this site shows pricing clearly on the services page" or "I like how calm and uncluttered this homepage feels" gives them something to work with.

Include examples of what you do not want as well, since knowing that early saves a round of revisions. If you have existing brand guidelines, logo files, fonts, or colors, gather them too.

List what the site actually has to do

Functional requirements are where quotes vary most, so spell them out. Think in terms of what a visitor or a staff member needs to be able to do, for example:

• Submit an enquiry form that reaches the right person or team
• Book an appointment or class and receive a confirmation
• Buy products, pay online, and track an order
• Log in to an account area to view documents or history
• Let staff update pages, news, or listings without a developer
• Search or filter a large catalog or directory

Next, list integrations. Does the site need to connect to a CRM, an email marketing tool, a payment gateway, an accounting system, inventory software, WhatsApp, or a booking platform you already use? Name the specific tools where you can. An integration with a well-documented service is a very different job from connecting to an older internal system with no public API.

Be honest about budget, timeline, and who decides

Many businesses hold back their budget, worried that sharing it means the quote will rise to meet it. In practice, a realistic range helps a good developer recommend what fits, suggest what to phase into a later stage, and tell you early if your expectations and budget do not match. Without a range, you often get quotes that are impossible to compare because each one assumes a different scope.

For timeline, separate real constraints from preferences. A launch tied to an admissions season, a trade show, or a product release is a hard date. "As soon as possible" is not, and it is worth saying which you have.

Finally, be clear about who makes decisions. If final approval sits with a partner, a board, or a founder who will not be in the early meetings, say so. Feedback that arrives late from someone who was not involved is a frequent cause of rework. Ideally, name one person as the day-to-day contact who can gather feedback and give a single, consolidated answer.

Check you have access to what you own

Before work begins, make sure you can log in to the accounts that hold your online presence. Find out:

• Where your domain is registered, and whose name and email the account is under
• Who hosts the current site and whether you have the login
• Who controls DNS settings, which may be separate from the registrar
• Who manages business email, if it runs on the same domain
• Logins for Google Search Console, Google Analytics, and Google Business Profile, if they exist
• Admin access to the current website, if you are replacing an existing site

If a former employee or a previous agency set these up under their own accounts, start recovering access now. These are your business assets, and you should hold the keys.

A short pre-brief checklist

1. Write down the site's main goals, ranked, and how you will judge success.
2. Describe your key audiences and how they are likely to use the site.
3. Draft a list of pages with a line about each one's purpose.
4. Decide who will write and supply content, images, and product data.
5. Collect three to five example sites, with notes on what you like or dislike.
6. List the features and specific integrations you need.
7. Agree on a budget range you are comfortable sharing.
8. Note any fixed deadlines and periods when reviewers are unavailable.
9. Name the decision makers and one day-to-day contact.
10. Confirm access to your domain, DNS, hosting, and analytics accounts.

Your next step

You do not need every answer to be final before you start a conversation. A brief that says "we are unsure about this part" is far more useful than one that skips it. Work through the checklist, put your notes into a single document, and share it with the developers you are speaking to. You will get quotes that are easier to compare and a project that starts on firmer ground. If you would like a second pair of eyes on your brief, you are welcome to get in touch with Moonlighters.