How to brief a web developer you have never met

When you hire a developer in another time zone, the brief is the meeting you would have had in person. A good one gets you accurate quotes, fewer surprises, and a site that does what you needed. A vague one gets you three quotes that cannot be compared and a project that changes shape halfway through.

You do not need technical language to write a good brief. You need to answer a few questions honestly.

1. What must the site do?

Start with the job, not the pages. One or two sentences:

"Sell our 40 products to customers in the UK and take card payments."

"Get restaurant owners to book a demo call."

If a site has five goals, it has none. Pick the one that pays the bills and say it first. Everything else in the brief should support it.

2. Who is it for?

Describe the people who will use it. Where they are, what device they probably use, what they already know about you, and what makes them hesitate. "Busy office managers on their phones between meetings" leads to a different site than "engineers comparing specifications on a big screen".

3. Which pages do you think you need?

A rough list is fine: home, products, about, contact, and so on. Mark the ones you are sure about and the ones you are guessing. A good developer will suggest changes, but a starting list stops the scope from being invented in the quote.

4. Who provides the content?

This is where most projects stall. Be specific:

• Text: written by you, by a copywriter, or should the developer arrange it?
• Photos: do you have real ones, or will you use stock for now?
• Products: how many, and where does the data live today? A spreadsheet of 40 products is a small job. A supplier feed of 4,000 is a different project.

If content is not ready, say so. It changes the timeline more than anything technical does.

5. What does it need to connect to?

List every outside system the site has to work with:

• payment providers,
• shipping or delivery services,
• your email marketing tool,
• a CRM, booking system, or inventory system,
• analytics and ad accounts you already run.

Integrations are where hidden work lives. Naming them up front is the single best way to get an accurate quote.

6. Show examples, and say why

Share two or three sites you like, and one sentence each on what you like about them: "the product pages are easy to scan", "it feels calm", "checkout is fast on mobile". Links without reasons get copied in the wrong way.

7. Deadline, and what drives it

Give a date and the reason for it: a trade show, a product launch, a season. A real reason helps a developer plan what must be ready by then and what can follow in a second phase.

8. Budget range

Many buyers leave this out, hoping for a lower quote. It usually does the opposite. Without a range, a developer has to guess between a simple site and an elaborate one. With a range, they can tell you what is realistic, and what they would cut first to fit it.

9. Who decides?

Name the person who gives final approval, and anyone else who needs to see the work. Late feedback from someone who was not in the loop is the most common cause of expensive rework.

10. After launch

Say what happens once the site is live. Who hosts it, who updates it, and whether you want ongoing support. Also make sure you will own the domain, the hosting account, and the code. Put that in writing.

A template you can copy

Goal: What must the site do? (one or two sentences)
Audience: Who uses it, where, on what device?
Pages: The list, marking sure vs. guessing
Content: Who writes text, who supplies photos, how many products?
Integrations: Payments, shipping, email, CRM, analytics, ads
Examples: 2–3 sites and what you like about each
Deadline: Date and the reason for it
Budget: A range
Decision-maker: Who approves the work
After launch: Hosting, updates, support, ownership

A brief like this fits on one page and saves weeks. You can send us one on WhatsApp just as it is. We reply with questions before we reply with a price.