How to brief a web developer: a checklist that saves weeks

The single biggest factor in how smoothly a web project goes is not the technology. It is how clearly everyone understands what is being built and why.

You do not need to be technical to write a good brief. You need to explain your business, your goals and your constraints. A developer's job is to turn that into a plan.

1. Start with the goal, not the features

Explain what you want to change in your business:

• "We want more consultation bookings from people in our area."
• "Our staff spend two hours a day answering the same order-status calls."
• "We are launching a new product line and need to take pre-orders."

A good developer may suggest a simpler or cheaper way to reach the goal than the solution you had in mind (website, landing page or web app?).

2. Describe your customers

Who will use the site or app? How old are they, roughly? Are they mostly on phones? Do they know your field well, or are they beginners? What do they usually ask before buying?

3. List what it must do

Write a simple list of what visitors or users must be able to do. Split it into:

• Must have for launch,
• Nice to have if budget allows,
• Later, things you may want one day.

This list is the most useful thing in your brief. It lets developers quote properly and helps you decide what to cut if needed.

4. Share examples

Collect three to five websites you like, and a couple you dislike, and say why. "I like how this one shows prices clearly." "This one feels cluttered." Examples communicate taste faster than any description.

5. Content: who provides what

Be clear about:

• who writes the text,
• whether you have good photos or need a shoot,
• whether you have a logo and brand colours,
• how much existing content needs to move from an old site.

Content is the most common cause of delays. Projects rarely wait for code; they wait for words and pictures.

6. What already exists

List your current domain, hosting, website, and tools you already use and want to keep: accounting software, a booking system, a payment gateway, a CRM. Anything the new system must connect to affects the plan.

7. Budget and timeline

Share a budget range, even a rough one. It is not about being taken advantage of. It lets the developer suggest what is realistic for that amount, rather than guessing. Also mention any fixed dates, such as a launch event or a festival season.

8. Who decides

Name the person who will give feedback and approve each stage. Projects slow down when feedback comes from five people with different opinions. One decision-maker (who can consult others) keeps things moving.

A ready-to-use checklist

Copy this into a document and fill it in:

1. About the business, in three sentences.
2. The main goal of the project.
3. Who the users are.
4. Must-have features.
5. Nice-to-have and later features.
6. Websites you like and dislike, and why.
7. Content: text, photos, logo, and who provides each.
8. Existing domain, hosting and tools.
9. Budget range.
10. Ideal launch date and any fixed deadlines.
11. Who approves the work.

With this in hand, any good developer can give you an accurate proposal, and you can compare quotes on equal terms (how to compare quotes).