How to Brief a Web Developer When You're Not Technical®

One of the most common reasons web development projects go wrong is a bad brief.

Not because the client didn't know what they wanted. But because they didn't know how to communicate it in a way a developer could act on.

The result is a quote that doesn't match the project, a build that doesn't match the vision, and a client who feels like they were never really understood.

Here's a simple framework for briefing a web developer - no technical knowledge required.

The 5 things every brief needs

1. The problem you're trying to solve

Don't start with "I need a website" or "I need an app." Start with the problem.

"My team spends 3 hours every Monday manually pulling data from different tools to compile a weekly report."

"My clients keep calling to ask where their order is because we have no way to show them automatically."

"We're losing leads because nobody is following up and there's no system tracking who needs to be contacted."

A developer who understands your problem can design a solution. A developer given a vague feature list builds what was specified - not necessarily what you need.

2. Who will use it

Every system has users. Define yours.

"The main users are our 5 operations staff who need to update delivery statuses throughout the day."

"Our clients will log in to check their order status. They're not technical - it needs to be very simple."

"Our management team will use it to view reports. Our drivers will use it on their phones in the field."

Different users need different things. A developer who knows who's using the system builds it for them.

3. What they need to be able to do

List the core actions each type of user needs to take. Don't worry about how it works - focus on what it does.

"Operations staff need to: add new shipments, update delivery status, assign drivers, and view today's schedule."

"Clients need to: log in to their portals, see their order history, and download invoices."

"Managers need to: see a summary of all active orders, on-time delivery rates, and driver performance."

4. What you already have

Tell the developer about any existing tools or systems the new build needs to work with.

"We use QuickBooks for accounting." "We use a CRM called HubSpot." "We have a database in Excel that would need to be migrated."

Integrations affect complexity and cost. The developer needs to know upfront.

5. Timeline and budget

Be honest about both. Developers who know your budget can tell you what's achievable within it - rather than quoting for something that blows your budget and having to scale back later.

If you don't have a fixed budget, give a range. "We're thinking between $3,000 and $6,000." That's enough to give a developer direction.

What to do with this information

Write it down as a short document - even a few paragraphs. Then send it to the developer before any call or meeting.

A developer who reads a clear brief can give you a more accurate quote, spot potential issues early, and hit the ground running faster.

At CraftWave, every project starts with a written brief over email. We ask questions, clarify details, and agree on exactly what's being built before we start.

If you'd like help structuring your brief or you want to send us what you have and get feedback - email us at hello@thecraftwave.com.